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(54) Scheme for label switched path loop detection at node device 

(57) A node device and a label switched path loop 
detection method which are capable of detecting a label 
switched path loop efficiently and quickly are disclosed. 
In a node device for carrying out the label switching, an 
ingress node information is included in a message that 
is to be successively transmitted from the upstream side 
in order to set up a label switched path, and the fact that 
the message with the same ingress node information for 
the same packet flow will be received from a previous 
hop node that is different from before if the label 
switched path has a loop formed thereon is utilized. 
Also, at a time of transmitting a message for the pur- 
pose of setting up a label switched path, if a node at 
which the label switched path for that packet flow 
already exists on the upstream or downstream side is 
encountered, this already existing label switched path is 
traced along the same or opposite direction as the flow, 
and the label switched path is set up if no loop is 
detected after tracing to the end. 
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Description 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 

[0001] The present invention relates to a node device 
having a label switched path loop detection function and 
a label switched path loop detection method. 

DESCRIPTION OF THE BACKGROUND ART 

[0002] In a network layer protocol in which IP (Internet 
Protocol) nodes are inter-connected on an NBMA (Non- 
Broadcast Multiple Access) network, there is a scheme 
for realizing high speed packet transfer called MPLS 
(Multi-Protocol Label Switching). 
[0003] In the MPLS, specific labels" are allocated to 
specific packet flows between nodes while a corre- 
spondence between an input side label and an output 
side label is stored at each node, and the label switch- 
ing is carried out at each node by referring to this infor- 
mation, so that the IP processing can be omitted and a 
high speed packet transfer can be realized. For exam- 
ple, in the case where the fink layer is ATM, VPI(Virtual 
Path ldentifier)/VCI (Virtual Channel Identifier) will be 
used as a label. A route through which the packet flow is 
label switched will be referred to as a label switched 
path. 

[0004] In the case of constructing the label switched 
path, the label allocation protocol is used. The label allo- 
cation protocol exchanges label allocation messages 
between nodes on a packet flow route in order to notify 
a correspondence between a flow identifier for identify- 
ing the packet flow in network global fashion and a label 
for identifying the packet flow in link local fashion. 
[0005] Usually, every time an IP packet passes 
through a node, a value of an TTL (Time To Live) field 
(or a hop limit field or their equivalents) within its packet 
header is decremented by one. and the IP packet is not 
forwarded any further when the TTL or the like becomes 
0. In this way it is possible to prevent a packet to stay in 
the network indefinitely even when there is a loop in the 
route. 

[0006] However, for a packet to be transferred by the 
label switched path, the IP processing will not be carried 
out at an intermediate node so that it is impossible to 
decrement the TTL or the like, and consequently the 
packet will not leave the label switched path forever if 
there is a loop in the label switched path. For this rea- 
son, it is necessary to provide a label switched path loop 
detection mechanism or a label switched path loop pre- 
vention mechanism in the label allocation protocol. 
[0007] To this end, in the conventional label allocation 
protocol, the following two methods are available: (1) a 
method in which an information on a hop count from an 
ingress router which originated a label allocation mes- 
sage with respect to the packet flow is included in the 



label allocation message, and it is judged that a loop is 
present when the hop count exceeds a threshold (see 
Dooian et al., Tag Distrfoution Protocol", Internet Draft, 
drafKioolan-tdp-spec-01.txt May 1997); and (2) a 

5 method in which each node that forwards the label allo- 
cation message sequentially adds its own address to 
the label allocation message* and it is judged that a loop 
is present when the own address is already written in 
the received label allocation message (see Rosen et al., 

w *A Proposed Architecture for MPLS", Internet Draft. 
draft-rosen-rrpls-arch-00.txt, July 1997). 
[0008] However, the above described method (1) has 
been associated with a problem that it takes a consider- 
able amount of time until the loop detection because the 

is presence of loop cannot be ascertained until the hop 
count exceeds the threshold. 
[0009] Note that in this method if a loop is actually 
formed or not cannot be ascertained, and even if a loop 
is actually formed, it is impossible to ascertain a node at 

20 which a loop is formed. 

[0010] On the other hand, the above descrbed 
method (2) has been associated with a problem that the 
size of the label allocation message becomes quite 
large. 

25 

SUMMARY OF THE INVENTION 

[001 1 ] ft is therefore an object of the present invention 
to provide a node device and a label switched path loop 
30 detection method which are capable of detecting a label 
switched path loop efficiently and quicWy, in the case of 
constructing a label switched path to which the loop 
detection based on the TTL field of the IP packet is not 
applicabla 

35 [0012] According to one aspect of the present inven- 
tion there is provided a node device for label switching 
entered packets by referring to an input label informa- 
tion capable of identifying a packet flow to be entered 
and a corresponding information for specifying at least 
40 an output side interface, the node device comprising: a 
memory unit for storing a flow ID capable of network 
globally identifying a packet flow and an ingress node 
information regarding an inp/ess node of a label 
switched path, according to one label allocation mes- 
45 sage requesting a set up of the label switched path 
which is received from one previous hop node; and a 
judging unit for judging whether a label switched path 
loop is formed or not according to from which node 
another label allocation message that contains an den- 
se tical flow ID and an identical inpjess node information 
as said one label allocation message is received. 
[0013] According to another aspect of the present 
invention there is provided a node device for transmit- 
ting packets to be label switched using an output label 
55 information capable of identifying a packet flow to be 
outputted, the node device comprising: a transmission 
unit for transmitting a label allocation message request- 
ing a set up of a label switched path that contain at least 
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an information on said node device as an ingress node 
information regarding an ingress node of the label 
switched path; and a judging unit for judging that a label 
switched path loop rs formed upon receiving a label allo- 
cation message in which the ingress node information 
specifies said node device as the ingress node. 
[0014] According to another aspect of the present 
invention there is provided a node device for label 
switching entered packets by referring to an input side 
label information capable of identifying a packet flow to 
be entered and a corresponding output label informa- 
tion capable of identifying the packet flew to be output- 
ted, the node device comprising: an exchange unit for 
exchanging with a neighboring node on a route of one 
packet flow a label allocation message requesting a set 
up of a label switched path which contains a flow ID 
capable of network globally identifying said one packet 
flow and an ingress node information regarding an 
ingress node of the label switched path; and a judging 
unit for judging whether a label switched path loop is 
formed or not when a label allocation message that 
contains a flow ID and an ingress node information that 
are matching with an existing label switched path is 
received, according to a change in the input side label 
information for the existing label switched path. 
[0015] According to another aspect of the present 
invention there is provided a node device for label 
switching entered packets by referring to an input side 
label information capable of identifying a packet flow to 
be entered and corresponding one or a plurality of out- 
put label information capable of identifying the packet 
flow to be outputted, the node device comprising: an 
exchange unit for exchanging with each one of a previ- 
ous hop node and one or a plurality of next hop nodes 
on a route of one packet flew a label allocation message 
requesting a set up of a label switched path which con- 
tains an identifier for identifying said one packet flow 
and an ingress node information regarting an ingress 
node of the label switched path; and a judging unit for 
detecting whether or not a message containing an iden- 
tifier and an ingress node information that are identical 
to those of a previously exchanged message is received 
from a previous hop node different from one previous 
hop node from which the previously exchanged mes- 
sage is received, or whether or not a message that con- 
tains an identifier and an ingress node information that 
are identical to those of the previously exchanged mes- 
sage and changes the input side label information is 
received, and judging whether a label switched path 
loop is formed or not according to a result of detecting. 
[0016] According to another aspect of the present 
invention there is provided a node device for label 
switching entered packets by referring to one or a plural- 
ity of input side label information capable of identifying a 
packet flow to be entered and a corresponding output 
label information capable of identifying the packet flow 
to be outputted, the node device comprising: an 
exchange unit for exchanging with a neighboring node 



on a route of one packet flow a message for setting up a 
new label switched path or utilizing an existing label 
switched path, which contains an identifier for identify- 
ing said one packet flow and an ing-ess node informa- 

5 tion regarding an ingress node of the new label switched 
path or the existing label switched path; and a judging 
unit for detecting whether or not a message containing 
an identifier and an ingress node information that are 
identical to those of a previously exchanged message is 

10 received from a previous hop node device different from 
one previous hop node device from which the previously 
exchanged message is received, or whether or not a 
message that contains an identifier and an ingress node 
information that are identical to those of the previously 

is exchanged message and changes the input side label 
information is received, and judging whether a label 
switched path loop is formed or not according to a result 
of detectiong. 

[0017] According to another aspect of the present 

20 invention there is provided a node device for label 
switching entered packets by referring to an input side 
label information capable of identifying a packet flow to 
be entered and a corresponding output side label infor- 
mation capable of identifying the packet flow to be out- 

25 putted, and for merging label switched paths by setting 
one output side label information and a plurality of input 
side label information in correspondence for one packet 
flow, the node device comprising: a transmission unit for 
transmitting to a next hop node in an existing label 

30 switched path a hop count update message that con- 
tains at least an ingress node information after merging 
and an updated hop count value, upon receiving one 
label allocation message requesting a set up of one 
label switched path that contains at least a given ingress 

35 node information regarding an inyess node of said one 
label switched path and a given hop count value, when 
said one label allocation message requires merging to 
the existing label switched path and the given hop count 
value makes a hop count value of the existing label 

40 switched path updated to a larger value than a current 
value; and a judging unit for judging whether a label 
switched path loop is formed or not according to from 
which node another hop count update or label allocation 
message for an identical packet flow that contains an 

45 identical ingress node information as a previously 
received label allocation message is received. 
[0018] According to another aspect of the present 
invention there is provided a node device for label 
switching entered packets by referring to one or a plural- 

so rty of input side label information capable of identifying a 
packet flow to be entered and a correspond ng output 
label information capable of identifying the packet flow 
to be outputted, the node device comprising: an 
exchange unit for exchanging with a neighboring node 

55 on a route of one packet flow a message for setting up a 
new label switched path or utilizing an existing label 
switched path, which contains an identifier for identify- 
ing said one packet flow; a memory unit for storing an 
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information indicating a set ip of a label switched path 
corresponding to said message as pending until a 
response message corresponding to said message is 
received; and a judging unit for judging whether a label 
switched path loop is formed or not according to 5 
whether a not a message regarding a label switched 
path fa which the information indicating pencfing is 
stored in the memory unit according to a previously 
exchanged message is received. 
[0019] According to another aspect of the present 10 
invention there is provided a node device for label 
switching entered packets by referring to an input side 
label information capable of identifying a packet flow to 
be entered and a corresponding output side label infor- 
mation capable of identifying the packet flow to be out- is 
putted, and for merging label switched paths by setting 
one output side label information and a plurality of input 
side label information in correspondence for one packet 
flow, the node device comprising: a transmission unit for 
transmitting to a next hop node in an existing label 20 
switched path a hop count update message that con- 
tains at least an updated hop count value, upon receiv- 
ing one label allocation message requesting a set up of 
one label switched path that contains at least a given 
hop count value, when said one label allocation mes- 25 
sage requires merging to the existing label switched 
path and the given hop count value makes a hop count 
value of the existing label switched path updated to a 
larger value than a current value; a memory unit for stor- 
ing a correspondence between the input side label infor- 30 
mation and the output side label information for said one 
packet flow according to said one label allocation mes- 
sage, and storing an information indicating a storing of 
the correspondence as pending until a success mes- 
sage corresponding to the hop count update message 35 
is received; and a judging unit for judging whether a 
label switched path loop is formed or not accorting to 
whether or not a hop count update or label allocation 
message indicating a packet flow or a correspondence 
between the input side label information and the output 40 
side label information for which the information indicat- 
ing the storing of the correspondence as pending is 
stored in the memory unit according to a previously 
received label allocation message is received. 
[0020] It is to be noted that the present invention is 45 
equally realizable as a method of label switching loop 
detection in the node device as descrfoed above, or a 
computer usable medium having computer readable 
program codes embocfied therein for causing a compu- 
ter to function as the node device as described above, so 
[0021 ] Other features and advantages of the present 
invention will become apparent from the following 
description taken in conjunction with the accompanying 
drawings. 

ss 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0022] 



Fig. 1 is a schematic diagram for explaining an 
operation of a node device according to the first 
embodiment of the present invention 
Fig. 2 is a schematic diagram for explaining a case 
of bus type connection between neighboring nodes. 
Fig. 3 is a schematic diajyam for explaining a case 
of point-to-point link connection between neighbor- 
ing nodes. 

Fig. 4 is a schematic diagram for explaining an 
operation of a node device according to the second 
embodiment of the present invention. 
Fig. 5 is another schematic diagram for explaining 
an operation of a node device according to the sec- 
ond embodiment of the present invention. 
Fig. 6 is another schematic diagram for explaining 
an operation of a node device according to the sec- 
ond errtoodiment of the present invention. 
Fig. 7 is another schematic diagram for explaining 
an operation of a node device according to the sec- 
ond embodiment of the present invention. 
Fig. 8 is another schematic diagram for explaining 
an operation of a node device according to the first 
and second emboriments of the present invention. 
Fig. 9 is a schematic diagram for explaining an 
operation of a node device according to the third 
embodiment of the present invention 
Fig. 1 0 is another schematic diagram for explaining 
an operation of a node device according to the third 
embodiment of the present invention 
Fig. 11 is a diagram showing an exemplary format 
of a message such as a label allocation message 
that can used in the present invention. 
Fig. 12 is a diagram showing an exemplary format 
of a message such as a label allocation failure mes- 
sage that can be used in the present invention. 
Fig. 13 is a diagram showing one exemplary format 
of an entry of a flow table that can be used in the 
present invention. 

Fig. 14 is a flew chart for one exemplary operation 
of a node device according to the present invention 
at a time of label allocation message reception. 
Fig. 15 is a flow chart for one exemplary operation 
of a node device according to the present invention 
at a time of hop count update message reception. 
Fig. 16 is a flow chart for another exemplary opera- 
tion of a node device according to the present 
invention at a time of label allocation message 
reception. 

Fig. 17 is a diagram shewing another exemplary 
format of an entry of a flow table that can be used in 
the present invention. 

Fig. 18 is a flow chart for another exemplary opera- 
tion of a node device according to the present 
invention at a time of label allocation message 
reception. 

Fig. 19 is a flow chart for another exemplary opera- 
tion of a node device according to the present 
invention at a time of label allocation message 
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reception. 

Fig. 20 is a flow chart for another exemplary opera- 
tion of a node device according to the present 
invention at a time of hop count update message 
reception. 

Rg. 21 is a flow chart for another exemplary opera- 
tion of a node device according to the present 
invention at a time of hop count update message 
reception. 

Fig. 22 is a flow chart for another exenplary opera- 
tion of a node device according to the present 
invention at a time of label allocation message 
reception. 

Fig. 23 is a flow chart for one exemplary operation 
of a node device according to the present invention 
at a time of label release message reception. 
Fig. 24 is a flow chart for another exenplary opera- 
tion of a node device according to the present 
invention at a time of label release message recep- 
tion. 

Fig. 25 is a schematic cfiagram for explaining an 

operation of a node device according to the fourth 

embodiment of the present invention. 

Fig. 26 is another schematic diagram for explaining 

an operation of a node device according to the 

fourth embocfiment of the present invention. 

Fig. 27 is another schematic diagram for explaining 

an operation of a node device according to the 

fourth embodiment of the present invention. 

Fig. 28 is another schematic diagram for explaining 

an operation of a node device according to the 

fourth embodiment of the present invention. 

Fig. 29 is another schematic diagram for explaining 

an operation of a node device according to the 

fourth embodiment of the present invention. 

Fig. 30 is another schematic diagram for explaining 

an operation of a node device according to the 

fourth embodiment of the present invention. 

Fig. 31 is a flow chart for an exemplary operation of 

a node device according to the fourth embodiment 

of the present invention at a time of label allocation 

message reception. 

Fig. 32 is a schematic cfiagram for explaining an 

operation of a node device according to the fifth 

embodiment of the present invention. 

Fig. 33 is another schematic diagram for explaining 

an operation of a node device according to the fifth 

embodiment of the present invention. 

Fig. 34 is another schematic diagram for explaining 

an operation of a node device according to the fifth 

embodiment of the present invention. 

Fig. 35 is another schematic diagram for explaining 

an operation of a node device according to the fifth 

embodiment of the present invention. 

Fig. 36 is another schematic diagram for explaining 

an operation of a node device according to the fifth 

embodiment of the present invention. 

Fig. 37 is a flow chart for an exemplary operation of 



a node device according to the fifth embodiment of 
the present invention at a time of label allocation 
message reception. 

Rg. 38 is a block diagram showing an exemplary 
5 configuration of a node device according to the 
present inventioa 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

10 

[0023] Now, the preferred embodiments of the node 
device and the label switched path loop detection 
method according to the present invention wfll be 
descrfoed in detail with references to the drawings. 
is [0024] In short, in one aspect of the present invention, 
an ingress node information is included in a message 
that is to be successively transmitted from the upstream 
side in order to set up a label switched path, and the fact 
that the message with the same ingress node informa- 
nt) tion for the same packet flow will be received from a pre- 
vious hop node that is c§fferent from before if the label 
switched path has a loop formed thereon is utilized. 
[0025] Also, according to another aspect of the 
present invention, at a time of transmitting a message 
25 for the purpose of setting up a label switched path 
(which can be done either by the ingress node initiative 
where the message is transmitted from the ingress 
toward the downstream side or by the egress node initi- 
ative where the message is transmitted from the egress 
30 toward the upstream side), if a node at which the label 
switched path for that packet flow already exists on the 
upstream or downstream side is encountered, this 
already existing label switched path is traced along the 
same or opposite direction as the flow, by transmitting 
35 an update message, for example. Then, the label 
switched path is set up if no loop is detected after trac- 
ing to the end. 

[0026] By including the ingress node information in the 
message used in this tracing, the message with the 

40 same ingress node information for the same packet flow 
will be received from a previous hop node different from 
before if there is a loopi so that the loop can be detected 
by utilizing this tact Alternatively by setting a flag indi- 
cating that a state is pending at a time of transmitting or 

45 receiving the message, the message will arrive at a 
node which is indicated to be in a pending state by the 
flag for the same packet flow if there is a loop, so that 
the loop can be detected by utilizing this fact 
[0027] The present invention is applicable to both: (1 ) 

so the case (called Ingress Control) of generating a label 
switched path by an initiative of an ingress node, i.e.. the 
case in which a label allocation message is transmitted 
from the incjess node toward a next hop node, and a 
label allocation success/failure message is transmitted 

55 from the egress node toward a previous hop node; and 
(2) the case (called Egress Control) of generating a 
label switched path by an initiative of an ecjess node, 
i.e., the case in which a label allocation message is 
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transmitted from the egress node toward a previous hop 
node, and a label allocation success/failure message is 
transmitted from the ingress node toward a next hop 
node 

[0028] In the embodiments described below, either a 
confirmation flag or an ingress node information is used 
for the purpose of label switched path loop detection. 
[0029] Apart from the purpose of loop detection, the 
confirmation flag can also be utilized for the purpose of 
maintaining a consistency among label switched path 
states held at nodes over the entire network, in such a 
manner that, after a label allocation request message or 
update message is transmitted to a nextyprevious hop 
node, when another label allocation request message 
or update message is received from an upstream/down- 
stream node in a state of waiting for ACK to a transmit- 
ted message, a received message will not be accepted. 
[0030] The ingress node information can be used in 
detecting a loop quicker than the case of using the con- 
firmation flag. 

[0031] In the case of ingress node initiative (Ingress 
Control), the loop detection using only the confirmation 
flag is possfcJe when every node of the network carries 
out the label merging. In the case of egress node initia- 
tive (Egress Control), the loop detection using only the 
confirmation flag is possible both when every node of 
the network carries out the label merging as well as 
when some or all nodes of the network do not carry out 
the label merging. 

[0032] In the case of ingress node initiative (Ingress 
Control), it is preferable to use the ingress node infor- 
mation for the loop detection when every node of the 
network does not carry out the label merging or when 
the network includes nodes that carry out the label 
merging and nodes that do not carry out the label merg- 
ing. 

[0033] In the present invention, the hop count can be 
used for the purpose of setting an upper limit to the 
number of hops in the path, rather than for the purpose 
of loop detection. As a result, it becomes possfole to 
realize such controls as: (1) a control for decrementing 
the TTL (Time To Live) field of the IP packet at an 
entrance or exit of the label switched path as much as 
the number of hops in the path; (2) a control for prevent- 
ing the spiral loop formation in which the number of 
hops keep increasing, in the case of not carrying out the 
label merging (in the case of Ingress Control); and a 
control for carrying out the label merging without trans- 
mitting a message for notifying a change of state to a 
next hop node, with respect to the merging in which the 
maximum number of hops from the ingress does not 
change, in the case of carrying out the label merging. 
[0034] Note that, there are a variety of possfole proce- 
dures for the label switched path loop detection using 
different combinations of the hop count, the ingress 
node information, and the confirmation flag as informa- 
tion to be used. 

[0035] There are also a variety of ways for construing 



which packets belong to an identical packet flow, includ- 
ing: (1) a way in which packets with the same destina- 
tion IP address are construed as belonging to the 
identical packet flow; (2) a way in which packets with the 

5 same IP address portion corresponding to the network 
mask (i.e., prescribed upper bits of the destination IP 
address) are construed as belonging to the identical 
packet flow; (3) a way in which packets with the same 
set of source IP address and destination IP address are 

w construed as belonging to the identical packet flow; (4) 
a way in which packets with the same set of source IP 
address portion corresponding to the first network mask 
and destination IP address portion corresponding to the 
second network mask are construed as belonging to the 

is identical packet flow; (5) a way in which packets that 
pass through a node having some IP address are con- 
strued as belonging to the identical packet flow; and (6) 
a way in which packets with the same source and/or 
destination port numbers among those satisfying the 

20 criterion of any of the above described (1) to (5) are con- 
strued as belong to the identical packet flow. In the 
embodiments descrbed below, an exemplary case 
where packets with the same destination IP address are 
construed as belonging to the identical packet flow will 

2s be described. 

[0036] In the following, the embodiment directed to the 
case of Ingress Control in which the label allocation 
message is transmitted from the ingress node toward a 
next hop node and the label allocation success/failure 

30 message is transmitted from the egress node toward a 
previous hop node will be described first 

< First Embodiment ) 

35 [0037] Referring now to Rg. 1 to Rg. 3, the label allo- 
cation protocol and the node device for carrying out the 
label switching according to this label allocation protocol 
according to the first embodiment of the present inven- 
tion win be described. 

40 [0038] Here, it is assumed that the node device is sep- 
arately carrying out an exclusive control by which the 
node device refuses to receive a message that requires 
a change of state from the previous hop node while 
waiting for an ACK signal after the message transmis- 

45 sion to the next hop node. 

[0039] Rg. 1 shows an exemplary configuration of a 
network formed by connecting the node devices of this 
first embodiment together. 

[0040] In Fig. 1 , the node devices R1 to R5 of this first 
so embodiment are connected together, and in particular, a 
loop is formed by the node devices R2 to R5. Note that 
Rg. 1 only shows a part of the entire network and a part 
of a whole of the node devices R1 to R5 are actually 
connected with other node devices (not shown). 
55 [0041] Each of the node devices R1 to R5 has a func- 
tion for carrying out the IP (Internet Protocol) process- 
ing, as well as a function for carrying out the label 
switching according to the label allocation protocol of 
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this fffst embodiment In addition, except tor those node 
devices which are located at network ends and do not 
carry out any relaying, each node device also has a 
router function. For example, in Fig. 1 . each of the node 
devices R2 to R5 has the router function, while the 
router function is unnecessary for the router device R1 
as long as it is located at a network end and does not 
carry out any relaying. 

[0042] Also, in this first embodiment, it is assumed 
that each node device of the network does not carry out 
the label merging. 

[0043] The label switched path is formed by succes- 
sively transmitting a label allocation message to the 
respective next hop node devices, starting from an 
ingress node device. In this first embodiment, the label 
allocation message contains at least an ingress node 
information (Ingress), a flow ID (FTowid), and a link ID 
(UnkkJ). For the link ID, any one or a combination of two 
or more of a label, a layer 2 connection identifier, a label 
allocation message source node address, and a 
request identifier in the case where the label allocation 
is to be carried out by a downstream side node upon 
receiving the label allocation message (the case of 
Downstream on demand allocation) can be used. 
[0044] For the ingress node information, one of the IP 
addresses allocated to an output interface of the ingress 
node device is used. This IP address is a network global 
address so that the ingress node can be identified net- 
work globally in this case. 

[0045] The flow ID is an information for identifying a 
packet flow in network global fashion. 
[0046] The label contained in the message is 
assumed to be an information for identifying a packet 
flow in link local fashion, and so is the request identifier. 
[0047] The label switched path is actually established 
when the label allocation success message is succes- 
sively returned to the respective previous hop node 
devices starting from an egress node device, in 
response to the label allocation message described 
above Here, an exemplary label allocation protocol in 
which the label allocation or update success message is 
successively returned from the egress node after the 
label allocation or update message reached up to the 
egress node of the label switched path will be mainly 
descrbed, but it is also possible to employ such a label 
allocation protocol in which the label allocation or 
update success message is returned from an intermedi- 
ate node on a route of the label switched path to its pre- 
vious hop node device without waiting for the label 
allocation or update message to reach to the egress 
node and the label allocation or update success mes- 
sage to come back from there 
[0048] In this first embodiment an exemplary case in 
which the node that transmits the label allocation mes- 
sage (upstream side node) carries out the label alloca- 
tion (the case of Upstream allocation), that is, the case 
in which the "label" is contained in the label allocation 
message, will be descrfoed, but in the case of the 



Downstream on demand allocation, the label allocation 
message contains the "request identifier", and the label 
allocation success message to be returned in response 
contains the label" or the "layer 2 connection identifier". 

5 [0049] Each node device has an information on an 
interface ID for identifying input/output interfaces with 
respect to neighboring node devices. For a given packet 
flow, a set of the label allocated to the upstream side of 
the own node and the interface ID of the upstream side 

ro wiO be referred to as an input side label, and a set of the 
label allocated to the downstream side of the own node 
and the interface ID of the downstream side will be 
referred to as an output side label. Note that the inter- 
face ID may not necessarily be used at a node that has 

is only one interface. Here, for the sake of explanation, the 
node device R2 is assumed to have the interface IDs 
11" with respect to the node device R1, "i5" with respect 
to the node device R5, and "i3" with respect to the node 
derice R3. 

20 [0050] Then, in the case of actually carrying out the 
packet transfer using the established label switched 
path, the packet transfer by omitting the IP processing 
(i.e., the label switching) is carried out by referring to a 
correspondence between the input side label and the 

25 output side label according to the label information con- 
tained in a packet 

[0051 ] In the case where the label allocation message 
transmitted from the previous hop node or the label allo- 
cation success message to be returned by the own 

30 node contains the "label", this "label" is going to be the 
label that constitutes the input side label. In the case 
where the label allocation message to be transmitted by 
the own node or the label allocation success message 
returned from the next hop node contains the "label", 

35 this label" is going to be the label that constitutes the 
output side label. 

[0052] On the other hand, when the label allocation 
message or the label allocation success message con- 
tains the layer 2 connection identifier" rather than the 

40 "label", the label that is separately obtained in corre- 
spondence to this layer 2 connection identifier is going 
to be the label that constitutes the input side label or the 
output side label. More specifically, in the case of using 
ATM as the link layer and the network configuration in 

45 which an ATM switch is provided between the neighbor- 
ing nodes, it is the VPI/VCI that is used as the label" in 
the actual switching, but the value win be rewritten at 
the intermediate ATM switch, so that another identifier 
called VOID (Virtual Connection ID) wfll be used so that 

so the ATM connection between the neighboring nodes 
can be uniquely identified by the both end-nodes. This 
VCID is an example of the "layer 2 connection identifier" 
that can be contained in the label allocation protocol. 
[0053] By combining the above descrfoed link ID" that 

55 is contained in the message with the interface ID at 
which the message is received, the node that received 
the label allocation message or the (hop count) update 
message can detect the fact that the message is 
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received from a previous hop node that is different from 
the one from which the label allocation message with 
the same flow ID and the same ingress node informa- 
tion were received before. In such a case, it is judged 
that there is a loop. 

[0054] Note that, in the case where the upstream side 
neighboring node does not have the above descrfoed 
loop detection function, there can be cases of receiving 
the label allocation message with the same flow ID and 
the same ingress node as before but which contains a 
different label (or layer 2 connection identifier or request 
identffier), from the same previous hop node as before. 
In such a case, the node that received this message will 
carry out the loop detection on behalf of the upstream 
side neighboring nod a 

[0055] Consequently, it is also possible to provide the 
loop detection function not for explicitly detecting 
whether the message with the same flow ID and the 
same ingress node information is received from a previ- 
ous hop node that is different from before or not, but for 
detecting whether the message with the same flow ID 
and the same ingress node information but which con- 
tain a label (or layer 2 connection identifier or request 
identifier) that is different from before is received or not 
In this manner, using the single criterion, each node 
device carries out the detection as to whether the mes- 
sage is received from a different previous hop node or 
not if the upstream side neighboring node has the bop 
detection function, or the detection as to whether a dif- 
ferent label is received or not if the upstream side neigh- 
boring node has no loop detection function so as to 
detect a loop that has been overlooked at the upstream 
side, 

[0056] In the following, the case of using the label" as 
the link ID" will be descrfoed. In the case of using 
something other than the label as the link ID, the loop 
detection can be realized similarly by replacing the 
"label" in the following description with the "layer 2 con- 
nection identifier, the "label allocation message source 
node address", the "request identifier", or a combination 
of any two or more of these and the "label". For exam- 
ple, a set of the layer 2 connection identifier", the label 
allocation message source node address" or the 
"request identifier and the interface ID of the upstream 
side is going to be referred to as the input side label. 
[0057] Note however that in the example described 
below, the Input side label" is used not only for detect- 
ing whether the message with the same flow ID and the 
same ingress node information is received from a previ- 
ous hop node that is different from before or not (for 
judging that there is a loop when the previous hop node 
is different), but also for detecting whether the message 
with the same flow ID is received from the same previ- 
ous hop node as a message with a different ingress 
node information or not (for continuing a new label 
switched path set up when the ingress node information 
is different), so that in the case where the upstream side 
neighboring node does not carry out the label merging, 



it is preferable to replace the "label" with the layer 2 
connection identifier* or the "request identifier" (either 
one alone) or else the combination of the "label alloca- 
tion message source node address" and the other fink 

5 ID, rather than with the "label allocation message 
source node address" alone. 
[0058] Note also that in the description gven above 
and below, the fact that the label allocation message 
with the same flow ID and the same ingress node infor- 

w mation is received from a different previous hep node is 
detected (judged as a loop) using the link ID" contained 
in the message, but there is also a case where this 
detection can be done by using only the "interface ID" 
from which the message is received. This is the case 

75 when the neighboring nodes are connected not by a bus 
type connection as shown in Rg. 2 but by a point-to- 
point link as shown in Rg. 3. Note here that it is prefera- 
ble to use such a loop detection using the interface ID 
alone (without relying on the link ID) instead of the input 

20 side label only when the upstream side neighboring 
node carries out the label merging. 
[0059] Also, in the case of Rg. 2, the loop is to be 
detected using the link ID (the label, for example), and 
the label or request identifier is to be allocated by each 

25 upstream side node such that values coming from differ- 
ent previous hop nodes appear different from a view- 
point of the downstream side node. 
[0060] Rg. 1 shows the label allocation messages ml , 
m2, m3, m4 and m5 that are sent from R1 to R2, from 

30 R2 to R3, from R3 to R4, from R4 to R5, and from R5 to 
R2, respectively. 

[0061 ] Here, mi = (ingress node (Ingress) = x1 , flow ID 
(Flowid) = x2, label = x3) indicates the label allocation 
message ml which contains xl as the ingress node 
35 information, x2 as the flow ID, and x3 as the label. 
[0062] As for the timing at which the node device 
transmits the label allocation message as an ingress 
node, the following options are available, for example 

40 (1) Each node device transmits the label allocation 
message at a timing where the routing table with 
respect to the destination "dest" is created. 

(2) Each node device transmits the label allocation 
message at a timing where the amount of traffics 

45 with respect to the destination "dest" exceeds a 
threshold after the routing table with respect to the 
destination "dest" is created. 

(3) Only a node device that satisfies the concfitions 
that the amount of traff ics with respect to the desti- 

50 nation "dest" exceeds a threshold after the routing 
table with respect to the destination "dest" is cre- 
ated, and that the previous hop node device of the 
traffic (datagram) does not support the label alloca- 
tion protocol according to this first embodiment, 

55 transmits the label allocation message by judging 
the own node as the ingress node at this timing 
(see INTERNET-DRAFT <drafHetf-rolc-nhrp-11.txt 
NBA Next Hop Resolution Protocol (NHRP), for 
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example). 

[0063] Next, the operation according to the label allo- 
cation protocol of this first embodiment will be 
described 

[0064] Here, an exemplary case where the route of a 
packet destined to the destination "dest" from the node 
device R1 is looping along the sequence of R1, R2, R3, 

R4, R5, R2, R3. wOl be descrfoed. 

[0065] Rrst, the node device R1 allocates a new label 
"a" at the output interface to the node device R2 which 
is a next hop node of the own node with respect to the 
destination "dest", and transmits the label allocation 
message ml (in&ess node = R1, Mow ID = dest, label = 

a) to the node device R2, at a timing where the routing 
table with respect to the destination "dest" is created, for 
example, as described above. Also, the node device R1 
stores at least the flow ID, the inp/ess node information, 
and the output side label, in correspondence, and 
attaches an information that indicates pending. 
[0066] Upon receiving the label allocation message 
ml from the node device R1 , the node device R2 allo- 
cates a new label "b" at the output interface to the node 
device R3 which is a next hop node of the own node, 
and transmits the label allocation message m2 (ingress 
node = R1, flow ID = dest, label = b) to the node device 
R3. Also, the node device R2 stores the label switching 
information, i.e., at least the flow ID, the ingress node 
information, the input side label (the received label and 
the link ID with respect to the node device R1), and the 
output side label (the allocated label and the link ID with 
respect to the node device R3), in correspondence, and 
attaches an information that indicates pending. Thus, at 
this point the node device R2 stores therein at least the 
flow ID "desT, the ingress node information "R1", the 
input side label "(i1, a)", and the output side label "03, 

b) ", in correspondence. 

[0067] Note that each information mentioned above is 
to be stored by using one or plural tables (such as a flow 
table shown in Fig. 1 3), for example. Also, as for a timing 
for storing each information mentioned above, it is pos- 
sble to store all of them collectively before or after 
transmitting the label allocation message m2, for exam- 
ple, or it is possible to store the flow ID, the ingress node 
information and the input side label when the label allo- 
cation message ml is received and store the output 
side label after the label V is allocated, for example. 
[0068] Similarly, as the label allocation message is 
successively forwarded from R3 to R4, from R4 to R5, 
and then from R5 to R2, the allocation of a label at the 
output interface, the storing of each information such as 
the flow ID, and the attaching of an information that indi- 
cates pending are carried out at each of the node 
devices R3 to R5. 

[0069] Next, when the node device R2 receives the 
label allocation message m5 (initial node = R1, flow ID 
= dest label = e) from the node device R5, the node 
device R2 judges that there is a loop because, in rela- 



tion to the set of information such as the flow ID that is 
already stored in response to the reception of the label 
allocation message ml from the node device R1 ( this 
message has the same ingress node information and 

5 the same flew ID but a different input side label ((i1 , a) 
as oppose to (i5, e)), so that the node device R2 either 
discards the received label allocation message m5 or 
returns a label allocation failure message to the node 
device R5. In this example, it is assumed that the node 

w device that detected the loop returns the label allocation 
faOure message. 

[0070] When the label allocation failure message is 
received in this manner, the node device R5 cancels the 
output side label information that was stored at a time of 

75 transmitting the label allocation message m5 among a 
set of information such as the flow ID, and changes the 
information that indicates pending into an information 
that indicates confirmed, and transmits a label alloca- 
tion success message to the previous hop node device. 

20 [0071] Also, the node device other than the ingress 
one which received the label allocation success mes- 
sage from the next hop node device (R4, R3 and R2 in 
this example) transmits the label allocation success 
message to the previous hop node device. Also, the 

2s node device which received the label allocation success 
message (R4, R3, R2 and R1 in this example) changes 
the information that indicates pending that is attached to 
a set of information such as the flow ID that was stored 
in response to the label allocation message, into an 

30 information that indicates confirmed. 

[0072] As a result the label switched path in the 
sequence of R1. R2, R3, R4 and R5 is formed. Also, the 
usual IP transfer using the TTL (Time To Live) field, the 
hop limit field or their equivalents of an IP packet is car- 

35 ried out from the node device R5. 

[0073] Note that such a state is a transient state, and 
the routing protocol operates such that a normal route is 
recovered after a prescribed period of time elapses, 
while the change of the label switched path is also car- 

40 ried out in conjunction with that 

[0074] ff the label allocation message reaches to the 
egress node without detecting any loop, this egress 
node device transmits the label allocation success mes- 
sage to the previous hop node device, and then the 

45 label allocation success message is successively trans- 
mitted to the respective previous hop node devices until 
finally reaching to the ingress node device, so that a 
loop-free label switched path is formed. 
[0075] Note that it is also possible to modify the first 

so embodiment to use the conventional method for detect- 
ing a loop when the hop count exceeds a threshold in 
addition. 

[0076] Note also that when the node device of this f irst 
embodiment becomes the egress node of the label 
55 switched path, it is preferable to transmit the label allo- 
cation message repeatedly at appropriate timings 
thereafter. There can be various reasons for returning 
the label allocation failure message such as that a loop 
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is detected or that there is no available label, but in 
some cases there is a possibility for being able to 
extend the label switched path further as a result of hav- 
ing a previously detected loop resolved when the rout- 
ing table is rewritten, or having an available label 5 
secured when the previously used label is released. 
Note however that when the hop count exceeding the 
threshold is the reason for the label allocation failure, 
the repeated transmission of the label allocation suc- 
cess message at appropriate timings should not be 10 
made. As for the reason for the label allocation failure, it 
is preferable to transmit it to the previous hop node 
device by writing it into the label allocation failure mes- 
sage at the node device. 

[0077] Now, the case where the node device discards is 
the received label allocation message upon judging that 
there is a loop will be described. 
[0078] The node device (R2 in this example) that 
detected the loop repeatedly carries out the procedure 
for re-transmitting the label allocation message if the 20 
label allocation success message is not returned from 
the node device (R5 in this example) which originally 
transmitted the label allocation message that resulted in 
the loop detection, after a preserved period of time 
since the transmission of the label allocation message. 25 
Then, when the number of repeated re-transmission 
exceeded a threshold, it is regarded that the label allo- 
cation failure message was returned. Note that it is pref- 
erable to provide this function also in the case of using 
the node device which returns the label allocation failure 30 
message when it is judged that there is a loop. 
[0079] Each upstream side node device (such as R4 
in this example) of the node device (R5 in this example) 
which originally transmitted the label allocation mes- 
sage that resulted in the loop detection to the node 35 
device (R2 in this example) which detected the loop will 
also re-transmit the label allocation message as the 
label allocation success message is not returned after a 
preserved period of time has elapsed since the trans- 
mission of the label allocation message. Here, when the 40 
label allocation message with the same flow ID. the 
same input side label and the same ingress node infor- 
mation (the label allocation message with the same flow 
ID, the same input side label, the ingress node informa- 
tion, and the same hop count in the case of using the 45 
hop count as well) is received, the node device is to 
return the label allocation success message in 
response to this. Therefore, for example, when the node 
device R4 re-transmits the label allocation message to 
the node device R5. the node device R4 is going to so 
receive the label allocation success message from the 
node device R5. 

< Second Embodiment ) 

ss 

[0080] Referring now to Fig. 4 to Fig. 8, the label allo- 
cation protocol and the node device for carrying out the 
label switching according to the label allocation protocol 
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according to the second embodiment of the present 
invention wiD be described. 

[0081 ] This second embodiment is basically similar to 
the first embodiment described above, so that the differ- 
ence from the first embodiment wiD be mainly described 
in the following. 

[0082] In this second embodiment, similarly as in the 
first embodiment each node device has a function for 
carrying out the IP (Internet Protocol) processing, as 
well as a function for carrying out the label switching 
according to the label allocation protocol of this second 
embodiment (inducfing the case of additionally using 
the hop count in the loop detection function of the first 
embodiment). In addition, except for those node devices 
which are located at network ends and do not carry out 
any relaying, each node device also has a router func- 
tion. Also, it is assumed that the node device is sepa- 
rately carrying out an exclusive control by which the 
node device refuses to receive a message that requires 
a change of state from the previous hop node while 
waiting fa an ACK signal after the message transmis- 
sion to the next hop node. 

[0083] This second embodiment differs from the first 
embodiment in particular in that, unlike the first embod- 
iment where it is assumed that each node device does 
not carry out the label merging, the node device of this 
second embodiment carries out the label merging by 
setting the identical output side label in correspondence 
to a plurality of input side labels with the same flow ID. 
In other words, the node device of this second embodi- 
ment has a function for carrying out a processing 
regarding the label merging as a function for carrying 
out the label switching. 

[0084] Note that it is not necessary for every node 
device to carry out the label merging, and there may be 
some node devices which do not carry out the label 
merging. The node device that carries out the label 
merging differs from the node device that does not carry 
out the label merging in having a function for transmit- 
ting a hop count update message in response to the 
label allocation message, prior to the label merging, and 
regarding the label merging as success when a hop 
count update success message is returned. 
[0085] In this second embodiment, at a time of receiv- 
ing the label allocation message, allocating a label at 
the output interface, and transmitting the label allocation 
message to the next hop node device, the node device 
stores at least the ingress node information, the flow ID, 
the input side label, the output side label, and the hop 
count (that is the number of hops from the ingress), in 
correspondence. Then, the node device that is trying to 
merge the labels in response to the label allocation 
message carries out the merging when the hop count 
hi of a new packet route to be merged now is less than 
or equal to the hop count h2 of a packet route to which 
the label switched path has already been set up, 
whereas when the hop count hi exceeds the hop count 
h2, this node device transmits to a next hop node a hop 
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count update message containing at least the ingress 
node information, the flew ID, the label, and the hop 
count prior to the merging. 

[0086] Here, in the case where the merging of the 
other path has already been made and a plurality of hop s 
counts with respect to different ingress nodes are 
already registered at this node device, the maximum 
hop count among them is taken as hmax, and the merg- 
ing is carried out when the hop count hi of a new packet 
route to be merged now is less than or equal to this hop 10 
count hmax, whereas when the hop count hi exceeds 
the hop count hmax, this node device transmits the hop 
count update message prior to the merging. 
[0087] The node device which received the hop count 
update message then transmits the hop count update 15 
message to the next hop node when the loop is not 
detected (by the similar method as in the first embodi- 
ment) and the hop count is less than or equal to a 
threshold, but in the case of receiving the hop count 
update message which has the flew ID and the ingress 20 
node information coinciding with but the input side label 
differing from the stored set of information such as the 
flew ID, or in the case where the hop count exceeds the 
threshold, it is judged that there is a loop. Note however 
that, in the case where the node device located at an 2s 
ending point of the label switched path receives the hop 
count update message and the loop is not detected 
while the hop count is less than or equal to the thresh- 
old, the label allocation message is transmitted to the 
next hop node instead of the hop count update mes- 30 
sage. 

[0088] Here, it is assumed that the threshold for the 
hop count is set to be 8. 

[0089] In the first embodiment, the messages to be 
exchanged between node devices included three mes- 35 
sages of the label allocation message, the label alloca- 
tion success message and the label allocation failure 
message, but in this second embodiment, there are 
three additional messages of the hop count update 
message, the hop count update success message and 40 
the hop count update failure message which are pro- 
vided for the sake of the merging. In addition, the hop 
count is described in each message. Note that as 
already mentioned above, the node device that does not 
carry out the label merging will not be a starting point for 4$ 
transmitting the hop count update message, but has a 
function for carrying out the processing upon receiving 
the hop count update message, the hop count update 
success message, or the hop count update failure mes- 
sage, so 
[0090] In this second embodiment it is assumed that 
the packets with the same destination IP address are 
construed as belonging to the same packet flew, simi- 
larly as in the first embodiment 

[0091] The ingress node information, the flow ID, the ss 
label, the link ID, the input side label, and the output side 
label are similar to the first embodiment 
[0092] Next the operation according to the label alk> 
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cation protocol of this second embodiment will be 
described with references to Fig. 4 to Fig. 7. 
[0093] Here, an exemplary case where the route of a 
packet destined to the destination "dest" from the node 
derice R1 is looping along the sequence of R1 , R2, R3, 

R4, R5, R2, re, and the label switched 

path along the sequence of R1, R2, R3, R4 and R5 is 
formed similarly as in the first embodiment and then a 
connection from the node devices R6, R7 and R8 to the 
node device R3 is formed and the label merging is to be 
carried out at the node device R3 wfll be described first 
Here, for the sake of explanation, it is assumed that the 
node device R3 has the link IDs of 12" with respect to 
the node device R2, 14" with respect to the node device 
R4, and 18" with respect to the node device R8, while 
the node device R1 has the Gnk ID of 11" at the output 
fink between the node devices R1 and R2. 
[Q094] First in Fig. 4, the node device R1 allocates a 
new label "a" at the output interface to the node device 
R2 which is a next hop node of the own node with 
respect to the destination "dest", and transmits the label 
allocation message ml (ingress node = R1, flow ID = 
dest, label = a, hop count => 1 ) to the node device R2, at 
a timing where the routing table with respect to the des- 
tination "dest" is created, for example, as described 
above. Also, the node device R1 stores at least the flow 
ID, the ingress node information, the output side label, 
and the hop count (= 0), in correspondence, and 
attaches an information that indicates pending. 
[0095] Upon receiving the label allocation message 
ml from the node device R1, the node device R2 allo- 
cates a new label tf at the output interface to the node 
derice R3 which is a next hop node of the own node, 
increments the received hop count and transmits the 
label allocation message m2 (ingress node = R1, flow 
ID = dest, label = b, hop count = 2) to the node device 
R3. Also, at appropriate timing, the node device R2 
stores at least the flow ID (= dest), the ingress node 
information (= R1), the input side label (= (i1, a)), the 
output side label (= fi3, b)), and the received hop count 
(= 1), in correspondence, and attaches an information 
that indicates pending. 

[0096] Similarly, as the label allocation message is 
successively forwarded from R3 to R4, from R4 to R5, 
and then from R5 to R2, the allocation of a label at the 
output interface, the storing of the set of information 
such as the flow ID, and the attaching of an information 
that indicates pending are carried out at each of the 
node devices R3 to R5. 

[0097] Next when the node device R2 receives the 
label allocation message m5 (initial node = R1, flow ID 
= dest label = e, hop count = 5) from the node device 
R5. the node device R2 judges that there is a loop 
because, in relation to the set of information that is 
already stored in response to the reception of the label 
allocation message ml from the node device R1, this 
message has the same ingress node information and 
the same flow ID but a different input side label ((M, a) 
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as oppose to fi5, e)), so that the node device R2 either 
discards the received label allocation message m5 or 
returns a label allocation failure message to the node 
device R5. 

[0098] Hereafter the processing is similar to the first s 
embodiment. 

[0099] As a result, the label switched path in the 
sequence of R1, R2, R3, R4 and R5 is formed. Also, the 
usual IP transfer using the TTL (Time To Live) field, the 
hop limit field or their equivalents of an IP packet is car- w 
ried out from the node device R5. 
[0100] Note that, as already mentioned above, such a 
state is a transient state, and the routing protocol oper- 
ates such that a normal route is recovered after a pre- 
scribed period of time elapses, while the change of the is 
label switched path is also carried out in conjunction 
with that. 

[0101] In adcfition, it is also judged that there is a loop 
when the hop count exceeds the threshold, and in such 
a case, the node device also either discards the 20 
received label allocation message or returns a label 
allocation failure message to the previous hop node 
device. 

[01 02] Next, the loop detection and the label switched 
path formation in the case of carrying out the label 2s 
merging wiD be described for an exerrplary case where, 
starting from a state of having the label switched path in 
the sequence of R1. R2, R3, R4 and R5 formed as 
shown in Fig. 4, new node devices R6, R7 and R8 are 
connected to form a topology as shewn in Fig. 5, and 30 
the node device R6 transmits the label allocation mes- 
sage. 

[0103] First, the node device R6 allocates a new label 
T at the output interface to the node device R7, and 
transmits the label allocation message m6 (ingress 35 
node = R6, flow ID = dest, label = f, hop count = 1) to the 
node device R7. Also, the node device R6 stores at 
least the flow ID, the ingress node information, the out- 
put side label, and the hop count (= 0), in correspond- 
ence, and attaches an information that indicates 40 
pending at this point. 

[0104] Upon receiving the label allocation message 
m6 from the node device R6. the node device R7 allo- 
cates a new label "g" at the output interface to the node 
device R8 which is a next hop node of the own node, 45 
increments the received hop count and transmits the 
label allocation message m7 (ingress node = R6, flow 
ID = dest, label = g, hop count = 2) to the node device 
R8. Also, at appropriate timing, the node device R7 
stores at least the flow ID, the ingress node information, so 
the input side label, the output side label, and the 
received hop count, in correspondence, and attaches 
an information that indicates pending. 
[0105] Upon receiving the label allocation message 
m7 from the node device R7, the node device R8 alio- ss 
cates a new label Vat the output interface to the node 
device R3 which is a next hop node of the own node, 
increments the received hop count and transmits the 



label allocation message m8 (in&ess node = R6, flow 
ID = dest label = h. hop count = 3) to the node device 
R3. Also, at appropriate timing, the node device R7 
stores at least the flow ID, the ingress node information, 
the input side label, the output side label, and the 
received hop count in correspondence, and attaches 
an information that indicates pending. 
[0106] Next when the node device R3 receives the 
label allocation message m8 from the node device R8, 
there is the set of information such as the flow ID (flow 
ID = dest ingress node information = R1, input side 
label = (i2, b), output side label = p4, c), hop count = 2) 
that is already stored in response to the label allocation 
message m2 received from the node device R2, and the 
flow ID is the same but the input side label is different 
and the ingress node information is also different, so 
that it is set to be a target of the merging. 
[0107] Here however, the maximum number of hops 
(hop count) from the ingress node increases from 2 to 3, 
so that the newly received label h and the already allo- 
cated output side label c are not set in correspondence 
immediately, and a hop count update message m9 
(ingress node = R6, flow ID = dest label = c, hop count 
= 4) for the purpose of updating the ingress node infor- 
mation and the hop count is transmitted to the down- 
stream side node device R4. Also, the node device R3 
stores at least the flow ID (= dest), the ingress node 
information (= R6), the input side label (= 08, e)), the 
output side label (= (4, c)), and the received hop count 
(= 3), in correspondence, and attaches an information 
that indicates pending. 

[0108] Note that in this second embodiment, the 
ingress node information to be written into the hop count 
update message is set to be the ingress node informa- 
tion regarding the ingress node for which the hop count 
from the initial node that is located on the upstream side 
from the node that transmits the hop count update mes- 
sage becomes maximum, but the loop detection is also 
possfole by writing the ingress node information in arbi- 
trary flow table entry for the flow of interest which has 
the common output side label into the hop count update 
message and transmitting such a hop count update 
message. 

[01 09] Upon receiving the hop count update message 
m9 from the node device R3, the node device R4 trans- 
mits the hop count update message m10 (in^ess node 
= R6, flow ID = dest, label = d, hop count = 5) to the 
node device R5 which is a next hop node of the own 
node. Also, the node device R4 stores the set of infor- 
mation such as the flow ID in correspondence and 
attaches an information that indicates pending, while 
holding the updated ingress node information R6 and 
the updated hop count value 4 for the set of information 
such as the flow ID that was stored in response to the 
label allocation message m3 before, and attaching an 
information that indicates updated pending. 
[0110] Upon receiving the hop count update message 
m10 from the node device R4, the node device R5 that 
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is at the ending point of the label switched path trans- 
mils the label allocation message ml 1 (ingress node = 
R6, flow ID = dest, label = e, hop count = 6) to the node 
device R2 which is a next hop node of the own node. 
Also, the node device R5 stores the set of information 5 
such as the flow ID in correspondence and attaches an 
information that indicates pending, while holding the 
updated ingress node information R6 and the updated 
hop count value 5 for the set of information such as the 
flow ID that was stored in response to the label all oca- 10 
tion message m4 before, and attaching an information 
that indicates updated pending. 
[0111] When the node device R2 receives the label 
allocation message ml 1 from the node device R5, there 
is the input side label "a" corresponding to the same 15 
flow ID that was already received from the node device 
D1, but the hop count value of this message is larger 
than the hop count value corresponding to the label "a", 
so that the received label = e and the output side label = 
b are not set in correspondence yet, and a hop count 20 
update message m12 (ing-ess node = R6, flow ID = 
dest, label = b, hop count = 7) in which the received hop 
count is incremented is transmitted to the node device 
R3 which is a next hop node of the own node. Also, the 
node device R2 stores at least the set of information 2s 
such as the flow ID in correspondence, and attaches an 
information that indicates pending. 
[0112] When the node device R3 receives the hop 
count update message m12 from the node device R2, 
the node device R3 has received the label allocation 30 
messages with the same ingress node = R6 and the 
same flow ID = dest but the different input side labels 
(i2, b) and (i8. e), so that it is judged that there is a loop, 
and this hop count update message m12 is discarded, 
while a hop count update failure message is transmitted 35 
to the node device R2. 

[0113] Upon receiving the hop count update failure 
message from the node device R3, the node device R2 
transmits the label allocation failure message to the 
node device R5 that had transmitted the label allocation 40 
message m11 for updating the hop count to the own 
device, while cancelling the set of information such as 
the flow ID that was stored in response to the label allo- 
cation message ml 1 . 

[0114] Hereafter, the message is to be successively 45 
transmitted from the node device R5 to its upstream 
side node devices (R5->R4->R3->R8^R7-» R6), 
and there are several options for the processing for this 
purpose. In the following, each of the following two 
cases will be described: (1) the case in which the node so 
device (R5 in this example) that received the label allo- 
cation failure message transmits the hop count update 
failure message to the upstream side node device (R4 
in this example) (the case of not allowing the merging); 
(2) the case in which the node device (R5 in this exam- ss 
pie) that received the label allocation failure message 
transmits the hop count update success message to the 
upstream side node device (R4 in this example) (the 



case of allowing the merging). 
[0115] First, the case (1) in which the node device (R5 
in this example) that received the label allocation failure 
message transmits the hop count update failure mes- 
sage to the upstream side node device (R4 in this exam- 
ple) (the case of not allowing the merging) will be 
descrfoed. 

[01 1 6] Upon receiving the label allocation failure mes- 
sage from the node device R2, the node device R5 
transmits the hop count update failure message to the 
node device R4 that had transmitted the hop count 
update message m10 to the own device, while cancel- 
ling the set of information such as the flew ID that was 
stored in response to the hop count update message 
m10. Also, for the set of information such as the flow ID 
that was stored in response to the label allocation mes- 
sage m4, the original ingress node information R1 and 
the original hop count value 4 are maintained, and the 
information that incficates updated pending is cleared. 
[0117] Upon receiving the hop count update failure 
message from the node device R5, the node device R4 
transmits the hop count update failure message to the 
node device R3 that had transmitted the hop count 
update message m9 to the own device, while cancelling 
the set of information such as the flow ID that was 
stored in response to the hop count update message 
m9. Also, for the set of information such as the flow ID 
that was stored in response to the label allocation mes- 
sage m3. the original ingress node information R1 and 
the original hop count value 3 are maintained, and the 
information that incficates updated pending is cleared. 
[0118] Upon receiving the hop count update failure 
message from the node device R4, the node device R3 
transmits the label allocation failure message to the 
node device R8 that had transmitted the label allocation 
message m8 for updating the hop count to the own 
device, while cancelling the set of information such as 
the flow ID that was stored in response to the label allo- 
cation message m8. 

[01 19] Hereafter, similarly as in the procedure of the 
first embodiment the node device R8 that received the 
label allocation failure message from the node device 
R3 transmits the label allocation success message to 
the node device R7 that had transmitted the label allo- 
cation message m7 to the own device, and the node 
device R7 transmits the label allocation success mes- 
sage to the node device R6 that had transmitted the 
label allocation message m6 to the own device. Also, 
the node device R7 cancels the output side label infor- 
mation among the set of information such as the flow ID 
that was stored at a time of transmitting the label alloca- 
tion message m7 upon receiving the label allocation 
message m6, and changes the information that indi- 
cates pending into the information that indicates con- 
firmed. The node device R6 changes the information 
that indicates pending that was attached to the set of 
information such as the flow I D that was stored at a time 
of transmitting the label allocation message m6 into the 



13 



25 



EP0896494A2 



26 



information that indicates confirmed. 

[0120] As a result as shown by a thick line in Fig. 6, 

apart from the label switched path in the sequence of 

R1, R2, R3, R4 and R5, another loop-free label 

switched path in the sequence of R6, R7 and R8 is s 

formed. 

[0121] Note that, in the case where the node device 
that had transmitted the label allocation message or the 
hop count update message that updates the hop count 
among the set of information such as the flow ID that io 
was already stored receives the label allocation suc- 
cess message or the hop count update success mes- 
sage in response, this node device transmits the label 
allocation success message or the hop count update 
success message corresponding to the previous hop 75 
node device that had transmitted the label allocation 
message or the hop count update message for updating 
the hop count to the own device, updates the hop count 
to the updated value, clears the information that indi- 
cates updated pending, and changes the information so 
that indicates pending that was attached to the set of 
information such as the flow ID that was newly stored at 
that time into the information that indicates confirmed. 
[0122] Next, the case (2) in which the node device (R5 
in this example) that received the label allocation failure 2s 
message transmits the hop count update success mes- 
sage to the upstream side node device (R4 in this exam- 
ple) (the case of allowing the merging) win be described. 
[01 23] Upon receiving the label allocation failure mes- 
sage from the node device R2, the node device R5 30 
transmits the hop count update success message to the 
node device R4 that had transmitted the hop count 
update message m10 to the own device, while deciding 
upon the set of information such as the flow ID that was 
stored in response to the hop count update message 3s 
m10. 

[0124] Upon receiving the hop count update success 
message from the node device R5, the node device R4 
transmits the hop count update success message to the 
node device R3 that had transmitted the hop count 40 
update message m9 to the own device, while changing 
the information that indicates pending that was attached 
to the set of information such as the flow ID that was 
stored in response to the hop count update message 
m9. Also, for the set of information such as the flow ID 4S 
that was stored in response to the hop count update 
message m9 into the information that indicates con- 
firmed. 

[0125] Upon receiving the hop count update success 
message from the node device R4, the node device R3 so 
transmits the label allocation success message to the 
node device R8 that had transmitted the label allocation 
message m8 for updating the hop count to the own 
device, while changing the information that indicates 
pending that was attached to the set of information such ss 
as the flow ID that was stored in response to the label 
allocation message m8 into the information that indi- 
cates confirmed. 



[01 26] Hereafter, similarly as in the procedure of the 
first embodiment, the node device R8 that received the 
label allocation success message from the node device 
R3 transmits the label allocation success message to 
the node device R7 that had transmitted the label allo- 
cation message m7 to the own device, and the node 
device R7 transmits the label allocation success mes- 
sage to the node device R6 that had transmitted the 
label allocation message m6 to the nvn devica Also, 
each of the node devices R8, R7 and R6 changes the 
information that indicates pending that was attached to 
the set of information such as the flow ID that was 
stored at a time of transmitting the label allocation mes- 
sage upon receiving the label allocation message into 
the information that indicates confirmed. 
[0127] As a result, as shown by a thick line in Fig. 7, a 
single tree shaped label switched path in which the label 
switched path in the sequence of R1, R2, R3, R4 and 
R5 and the label switched path in the sequence of R6, 
R7, R8, R3, R4 and R5 are merged at their common 
portion in the sequence of R3. R4 and R5 is formed. 
[0128] Note that in the case where the node device 
that had transmitted the label allocation message or the 
hop count update message that updates the hop count 
among the set of information such as the flow ID that 
was already stored receives the label allocation suc- 
cess message or the hop count update success mes- 
sage in response, this node device transmits the label 
allocation success message or the hop count update 
success message corresponding to the previous hop 
node device that had transmitted the label allocation 
message or the hop count update message for updating 
the hop count to the own device, updates the hop count 
to the updated value, clears the information that indi- 
cates updated pending, and changes the information 
that indicates perxfing that was attached to the set of 
information such as the flow ID that was newly stored at 
that time into the information that indicates confirmed. 
[0129] In the examples descrtoed above, the loop was 
detected before the hop count exceeds the threshold 8, 
but when the threshold for the hop count is smaller, 
there can be cases where it is judged as update failure 
because of the hop count exceeding the threshold 
before the loop is detected. 

[0130] Now, the operation described up to now is the 
case when the threshold for the hop count is set to be 8, 
but when the threshold for the hop count is greater than 
or equal to 5, that is, when the hop count update mes- 
sage generated at the node device R3 in conjunction 
with the connection of the node device R6 can for- 
warded up to the node device R3 that is the egress 
node, without having its hop count exceeding the 
threshold, and the hop count also does not exceed the 
threshold even at the node device R5, the hop count 
update success message is returned from the node 
device R5 to the node device R4 regardless of whether 
the node device R5 transmits the label allocation mes- 
sage to the node device R2 immediately or not and also 
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regardless of the outcome in the case of transmitting the 
label allocation message immediately. 
[01 31 ] In the following, the case where the threshold 
for the hop count is 4 while the node device R6 trans- 
mits the label allocation message m6 in a state shown in 
Fig. 5 will be described. 

[0132] In this case where the threshold for the hop 
count is 4. similarly as in the case where the threshold 
for the hop count is greater than or equal to 5, the label 
switched path in the sequence of R1, R2, R3, R4 and 
R5 is formed first 

[0133] Also, when the node devices R6, R7 and R8 
are connected next similarly as in the case where the 
threshold for the hop count is greater than or equal to 5, 
when the label allocation message with the ingress 
node = R6 is transmitted from the node device R6 first, 
this message is successively forwarded to the node 
devices R7, R8 and R3 while the hop count is sequen- 
tially incremented, and the hop count update message 
with the ingress node = R6 is forwarded to the down- 
stream side from the node device R3 while the hop 
count is sequentially incremented. 
[01 34] The hop count update message is then forward 
up to the node device R5 without having the hop count 
exceeding the threshold. The node device R5 that 
received the hop count update message judges that 
there is a loop because the received hop count exceeds 
the threshold, and returns the hop count update failure 
message to the node device R4 while cancelling the set 
of information such as the flow ID that was stored in 
response to the hop count update message. 
[0135] Upon receiving the hop count update failure 
message from the node device R5. the node device R4 
transmits the hop count update failure message to the 
node device R3 that had transmitted the hop count 
update message m9 to the own device, while cancelling 
the information that indicates pending that was attached 
to the set of information such as the flow ID that was 
stored in response to the hop count update message 
m9. 

[0136] Upon receiving the hop count update failure 
message from the node device R4. the node device R3 
transmits the label allocation failure message to the 
node device R8 that had transmitted the label allocation 
message m8 for updating the hop count to the own 
device, while cancelling the information that indicates 
pending that was attached to the set of information such 
as the flow ID that was stored in response to the label 
allocation message m8. 

[0137] Hereafter, similarly as in the procedure of the 
first embodiment, the node device R8 that received the 
label allocation failure message from the node device 
R3 transmits the label allocation success message to 
the node device R7 that had transmitted the label allo- 
cation message m7 to the own device, while cancelling 
the output side label information among the set of infor- 
mation such as the flow ID that was stored at a time of 
transmitting the label allocation message m8 upon 



receiving the label allocation message m7, and 
changes the information that indicates pending into the 
information that indicates confirmed. Also, the node 
device R7 transmits the label allocation success mes- 

5 sage to the node device R6 that had transmitted the 
label allocation message m6 to the own device. Also, 
each of the node devices R7 and R6 changes the infor- 
mation that indicates pending that was attached to the 
set of information such as the flow ID that was stored at 

10 a time of transmitting the label allocation message upon 
receiving the label allocation message into the informa- 
tion that indicates confirmed. 
[0138] In the above, some examples based on this 
second embodiment have been described, and in the 

is following, some variations of this second embodiment 
will be descrfred. 

[01 39] In the above, the node device R3 that received 
the hop count update message m12 from the node 
device R2 has been descrbed to detect the loop and 

20 transmit the hop count update failure message to the 
node device R2, but the node device that detected the 
loop upon receiving the hop count update message may 
be made to discard the hop count update message and 
not to transmit the hop count update failure message. 

25 [0140] Now, in the above, the node device R3 that 
received the hop count update failure message from the 
node device R4 has been described to transmit the 
label allocation failure message to the node device R8 
so that the newly formed label switched path was 

30 merely the route in the sequence of R6, R7 and R8. 
However, instead of that, it is also possible to form the 
new label switched path in the sequence of R6, R7, R8 
and R3 in such a way that the node device R3 does not 
carry out the label merging but transmits the label allo- 

35 cation success message to the node device R8 and 
cancels only the output side label without cancelling the 
entire set of information such as the flow ID that was 
stored in response to the label allocation message m8 
before, and becomes itself an ending point node. 

40 [0141] Also, in the above, the node device (R5 in the 
above example) which is the erring point of the label 
switched path transmits the label allocation message to 
the next hop node device of the own node upon receiv- 
ing the hop count update message. However, as 

45 already mentioned above, in the case where the node 
device is made to transmit the label allocation message 
repeatedly at appropriate timing when this node device 
itself becomes the erring point of the label switched 
path, when the node device R5 receives the hop count 

so update message from the node device R4 and the pre- 
scribed condition is satisfied, the node device R5 may 
transmit the hop count update message to the previous 
hop node device instead of transmitting the label alloca- 
tion message to the node device P2. and then transmit 

55 the label allocation message repeatedly at appropriate 
timing. 

[0142] Next, with reference to Fig. 8, the exemplary 
case where it is judged that there is a loop accorcfing to 
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the label allocation protocol of the first embodiment or 
the second embodiment in a situation where a loop in 
the route is actually not formed will be descrbed. 
[0143] As shewn in Fig. 8, suppose that the label 
switching in the sequence of R1. R2, FQ and R4 was s 
already formed from the node device R1 with respect to 
the destination "dest". and at some timing, the node 
device R3 breaks down so that the route from the node 
device R1 to the destination "dest" is changed to that in 
the sequence of R1, R2, R5 and R4. At this point, the w 
node device R2 releases the allocation of the label "b" 
to the node device R3 which is a next hop node toward 
the destination "dest", and transmits the label allocation 
message ml (ingress node = R1, flow ID = dest, label = 
d, hop count = 2) to the node device R5 which is a new is 
next hop node toward the destination "dest". Also, simi- 
larly as descrtoed above, the set of information such as 
the flow ID is stored. 

[0144] Upon receiving the label allocation message 
ml from the node device R2, the node device R5 alio- 20 
cates a new label "d" at the output interface to the node 
device R4 which is a next hop node of the node device 
R5, increments the received hop count, and transmits 
the label allocation message m2 (ingress node = R1, 
flow ID = dest, label = e, hop count = 3) to the node 25 
device R4. Also, similarly as described above, the set of 
information such as the flow ID is stored. 
[0145] UPon receiving the label allocation message 
m2 from the node device R5, the node device R4 
returns the label allocation failure message to the node 30 
device R5 without storing a correspondence of the label 
"e" and the flow ID, the ingress node information, etc., if 
the label "c" whose allocation is requested from the 
node device R3 is not yet released or if the hop count 
from the ingress node is already reaching to the thresh- 35 
old. At this point the reason for the label allocation fail- 
ure is written in the label allocation failure message 
[0146] On the other hand, upon receiving the label 
allocation message from the node device R5, the node 
device R4 stores a correspondence of the label and the 40 
flow ID, the in&ess node information, etc. from the node 
device R5, while returning the label allocation success 
message corresponding to the label allocation message 
to the node device R5, if the label "c" whose allocation 
is requested from the node device R3 is already 45 
released and the hop count from the ingress node is not 
yet reaching to the threshold. 
[0147] Upon receiving the label allocation failure mes- 
sage, the node device R5 re-transmits the label alloca- 
tion message regularly to the node device R4 as long as so 
the reason for the label allocation failure is other than 
the hop count exceeding the threshold. As a result, the 
label switched path in the sequence of R1, R2, R5 and 
R4 is formed by the label allocation message that is re- 
transmitted after the label "c" between the node device ss 
R3 and the node device R4 is released. 
[0148] As such, there are cases where a loop is 
detected even though a loop is actually not formed, in 



the case of the route change. In such a case, it is possi- 
ble to resolve the problem that many unnecessary label 
switched paths are formed temporarily under a situation 
where the route is changed frequently in the transient 
state of the routing protocol, by ensuring that there is 
always only one label that is corresponding to the spe- 
cific set (of the ingress node information and flow ID) 

(Third Embodiment) 

[0149] Referring now to Fig. 9 to Fig. 24, the label allo- 
cation protocol and the node device for carrying out the 
label switching according to this label allocation protocol 
according to the second embodiment of the present 
invention will be described. 

[0150] In this third embodiment, a network layer 
address allocated to the output interface of the ingress 
node and a local identifier allocated to the output inter- 
face of the ingress node are used as the ingress node 
information used in the first and second embodiments 
described abova 

[0151] In this case, it becomes possible to transmit a 
plurality of label allocation requests with respect to the 
same flow from a single ingress node, so that the label 
allocation protocol becomes flexible and it becomes 
easier to realize the inter-connection between different 
label allocation protocols, the set up of the label 
switched path corresponding to muttipath, etc. 
[0152] In the following, some examples of the label 
switched path formed by using a network layer address 
allocated to the output interface of the ingress node and 
a local identifier allocated to the output interface of the 
ingress node as the ingress node information will be 
described. 

[0153] In Fig. 9, the node devices R1 and R2 are node 
devices for setting up the label switched path using the 
conventional label allocation protocol, and the node 
devices R4 to R6 are node devices for setting up the 
label switched path using the label allocation protocol of 
this third embodiment. Also, the node device R3 is a 
node device which supports both the conventional label 
allocation protocol and the label allocation protocol of 
this third embodiment and connects the label switched 
paths formed by respective protocols. 
[0154] In Fig. 9, two label switched paths (LSPs) V 
and 2* are set up from the ingress node devices R1 and 
R2 with respect to the destination address "desT. In this 
case, the node device R3 is the ending point node of the 
label switched paths V and 2', and functions to extend 
these label switched paths using the label allocation 
protocol of this third embodiment Here, the label 
switched paths V and 2' have no ingress node informa- 
tion so that the node device R3 allocates local ID = 1, 2 
that are local at the output interfaces of the node device 
R3 to the label switched paths V and 2* in order to dis- 
tinguish these two paths. Using these, the label 
switched paths 1 and 2 which have the node device R3 
as the ingress node of the label switched path according 
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to the label allocation protocol of this third embodiment 
are set up, and when the set up is completed, the label 
switching between the label switched paths V and 1 as 
well as between the label switched paths 2' and 2 
becomes possible. 5 
[0155] Fig. 10 shows another example of the label 
switched path formed by using the local identifiers allo- 
cated to the output interfaces of the ingress node 
[0156] In Fig. 10, there are two routes from R1 to R5 
including a router ofR1->R2-*R3-»R5 and a route 
of R1 -» R2 -> R4-> R5. In the case of forming the label 
switched paths corresponding to these routes with 
respect to a flew of Flowid = R5. two label switched 
paths are going to be formed from the ingress node R1. 
In order to distinguish these paths, two different Ingress 
Local ID including Ingress Local ID = 1 and Ingress 
Local ID = 2 are used with respect to the same Ingress 
= R1. 

[0157] In the following, an exenplary message format 
an exemplary flow table format, and an exemplary node 
device operation procedure for each embodiment 
descrbed above will be descrbed. 
[0158] Fig. 1 1 and Fig. 12 show two exemplary mes- 
sage formats that can be used. The format of Fig. 11 is 
to be used for the label allocation message, the label 
allocation success message, the hop count update 
message, the hop count update success message, the 
label release message, and the label release success 
message, while the format of Fig. 12 is to be used for 
the label allocation failure message, the hop count 
update failure message, and the label release failure 
messaga Fig. 11 and Fig. 12 are identical except that 
an error code field is attached in the format of Fig. 12. 
[01 59] Note that in the case where the upstream side 
node allocates a label, the request ID field may be omit- 
ted. Also, in the case of not using the ingress node infor- 
mation, the ingress node address field and the ingress 
node local ID field may be omitted. Also, in the case of 
not using the hop count, the hop count field may be 
omitted, in which case the "hop count update message" 
will be referred to simply as "update message". 
[0160] In Fig. 1 1 and Fig. 12, the message type field 
indicates a type of message (the label allocation mes- 
sage, the label allocation success message, the label 
allocation failure message, the hop count update mes- 
sage, the hop count update success message, the hop 
count update failure message) to be used in the label 
allocation protocol. In the first embodiment, the label 
allocation message, the label allocation success mes- 
sage and the label allocation failure message are used, 
whereas in the second embodiment, the label allocation 
message, the label allocation success message, the 
label allocation failure message, the hop count update 
message, the hop count update success message, and 
the hop count update failure message are used. 
[0161] Also, the message length field indicates a 
length of an entire messaga The source node address 
and destination node address fields indicate network 



addresses of the source and destination nodes of this 
message, respectively. The ingress node address field 
indicates an address of a node which generated the 
label allocation message initially. The ingress node local 
ID field indicates a local ID of an ingress node which is 
necessary in setting up the label switched path with 
respect to the same flow ID from the same ingress 
node. 

[0162] In the first and second embodiments, the 
ing-ess node address constitutes the ingress node infor- 
mation. In this case, the ingress node local ID field is 
unnecessary. In the third embodiment, a set of the 
ingress node address and the ingress node local ID 
constitutes the ingress node information. 
[0163] Also, the hop count field indicates the hop 
count from the ingress node. The flow type field indi- 
cates a type of flow ID, the flew ID length field indicates 
a bit or octet length of the flow ID, and the flow ID field 
indicates the flow ID expressed in bit or octet length 
specified by the flow ID length. 
[0164] Also, the label field indicates a label allocated 
by the upstream side node in the case where the 
upstream side node allocates a label, or a label allo- 
cated by the downstream side node in correspondence 
to the request ID in the case where the downstream 
side node allocates a label (in which case the label field 
of the label allocation message transmitted from the 
upstream side node to the downstream side is either left 
empty or omitted). This label field may also indicate the 
layer 2 connection identifier. 

[0165] In the label allocation failure message in the 
format of Fig. 12, the error code field is attached in addi- 
tion to the fields of the label allocation message, where 
the reason for the label allocation failure is indicated by 
an error coda Here, seven error codes including those 
for "resource unavailable", "unknown label", "unknown 
flow type", "unknown flcwid", "refused by policy", "hop- 
count threshold exceeded", and "same flowid for same 
ingress info." are defined as indicated in Fig. 12. 
[01 66] Note that the node that received the label allo- 
cation failure message may choose either an operation 
to transmit the label allocation message repeatedly at 
appropriate timing or an operation to stop transmission 
of the subsequent label allocation message, according 
to the error code value. For example, the transmission 
of the subsequent label allocation message is stopped 
when the error code is "hopcount threshold exceeded", 
and the label allocation message is transmitted repeat- 
edly at appropriate timing for any other error coda 
[0167] Next Fig. 13 shows an exemplary format of a 
flow table to be used at the node device on which the 
label allocation protocol of the present invention oper- 
ates. 

[0168] The flow table registers a flow ID, an ingress 
node information (ingress node address or a set of 
ingress node address and ingress node local ID), an 
input side label (link ID, label), an output side label (link 
ID, label), a hop count an inyess flag indicating 
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whether rt is an ingress node or not, and an egress flag 
indicating whether it is an egress node or not. for the 
flow that is currently label switched. 
[0169] In the first and second embodiments, the 
ingress node local ID field is unnecessary. Also, in the s 
case of not using the hop count in the first embodiment, 
the hop count field is unnecessary. 
[0170] The ingress flag is set by the node device cor- 
responding to the ingress node information, at a time of 
transmitting the label allocation message. w 
[0171] The egress flag is set by the node device which 
is a destination of the flow specified by the flow ID or the 
node device whose next hop node does not support the 
label allocation protocol of the present invention, at a 
time of receiving the label allocation message, for is 
example. 

[01 72] Note that each node device can learn whether 
the neighboring node device is supporting the label allo- 
cation protocol of the present invention or not by carry- 
ing out communications with the neighboring node 20 
device either in advance or as the need arises, for 
example. 

[0173] Next. Fig. 14 shows an exemplary operation of 
the node device at a time of receiving the label alloca- 
tion message in the first embodiment or the second 25 
embodiment. 

[0174] When the label allocation message is received, 
an Update flag that indicates the hop count update is 
cleared first (step S1). and the flow table entry is 
sequentially taken out from the top of the flow table 30 
(steps S2, S3. S10. S11). When there is no flow table 
entry, the operation proceeds to the step S12. 
[0175] When rt is not an ingress node (the ingress flag 
is OFF) and the input side label in the entry is the same 
as the label in the received message (step S4 YES), 35 
whether the flow ID, the ingress node information and 
the hop count in the received message are the same as 
the values in the entry or not is checked (steps S19, 
S20, S21) and when they all coincide, the label alloca- 
tion success message is returned to the previous hop 40 
node (step S18). Otherwise, the label allocation failure 
message is returned to the previous hop node (step 
S22). In this case, the label allocation message recep- 
tion processing is terminated hera 
[0176] On the other hand, when it is an ingress node as 
(the ingress flag is ON) or the input side label in the 
entry is cfifferent from the label in the received message 
(step S4 NO), the flow ID is checked (step S5). When 
the flow ID is different the next flow table entry is 
checked (steps S10, S11). When the flow ID is the so 
same, whether the ingress node information is the same 
or not is checked (step S6). When the ingress node 
information is the same, the label allocation failure mes- 
sage is returned to the previous hop node (step S22). 
[01 77] When the ingress node information is different 55 
if the label merging is supported and the hop count in 
the received message is greater than the hop count in 
the entry (steps S7 YES. S8 YES), the Update flag is 



set (step S9). and the next flow table entry is checked 
(steps S10. S1 1). When the label merging is not sup- 
ported or the hop count in the received message is less 
than or equal to the hop count in the entry (step S7 NO 
or S8 NO), the next flew table entry is checked (steps 
S1 0. S1 1 ) while leaving the Update flag unchanged. 
[0178] When the check of the flow table entry is fin- 
ished to the end (step S10 YES), the hop count in the 
received message is checked (step S1 2). When the hop 
count exceeds the threshold, the label allocation failure 
message is returned to the previous hop node (step 
S22). When the hop count is less than or equal to the 
threshold, a flow table entry is newty created (step S1 3). 
[0179] Then, if it is not an egress node (the egress flag 
is OFF) (step S14 NO), the Update flag is checked (step 
S15), and when the Update flag is ON, the hop count 
update message is transmitted to the next hop node 
(step S1 7). When the Update flag is OFF, the label allo- 
cation message is transmitted to the next hop node 
(step S1 6). At this step S1 6, the label allocation success 
message may also be transmitted to the previous hop 
node. H it is an egress node (the egress flag is ON) (step 
S14 YES), the label allocation success message is 
transmitted to the previous hop node (step S18). 
[0180] Note that in the creation of the flow table entry 
at the step S13, the decision is kept pending, and con- 
firmed only when the label allocation success message 
is returned, as already described above. 
(0181] Also, in the case of not using the hop count, in 
Fig. 14, the output of the step S7 YES can be directly 
connected to the input of the step S9, the output of the 
step S2 NO and the output of the step S1 0 YES can be 
directly connected to the input of the step S13, and the 
output of the step S20 YES can be directly connected to 
the irput of the step S18. In this case, the update mes- 
sage will always be transmitted to the next hop node 
from the merging point if it is not an egress node, so that 
the number of messages to be transmitted increases 
compared with the case of using the hop count 
[0182] Next Fig. 15 shows an exemplary operation of 
the node device at a time of receiving the hop count 
update message in the second embodiment 
[0183] When the hop count update message is 
received, a Find flag and an Update flag are set to 0 
(step S31). and the flow table entry is sequentially taken 
out from the top of the flow table (steps S32, S33, S37, 
S38). When there is no flew table entry, the hop count 
update failure message is returned to the previous hop 
node (step S45). 

[0184] When it is not an ingress node (the ingress flag 
is OFF) and the input side label in the entry is the same 
as the label in the received message (step S34 YES), 
the Fmd flag is set to 1 (step S39), and whether the flow 
ID in the received message is the same as the value in 
the entry or not is checked (step S40), and if they do not 
coincide, the hop count update failure message is 
returned to the previous hop node (step S45). If they 
coincide, whether the hop count is the same as the 



18 



35 



EP0896494A2 



36 



value in the entry or not is checked (step S41). If the hop 
count is the same, the next flow table entry is checked 
(steps S37, S38), whereas if the hop count is different, 
the Update flag is set to 1 (step S42) and the next flow 
table entry is checked (steps S37, S38). 
[0185] On the other hand, when it is an ingress node 
(the ingress flag is ON) or the input side label in the 
entry is different from the label in the received message 
(step S34 NO), whether the flow ID in the received mes- 
sage is the same as the value in the entry or not is 
checked (step S35), and if they do not coincide, the next 
flow table entry is checked (steps S37. S38). If they 
coincide, whether the ingress node information in the 
received message is the same as the value in the entry 
or not is checked (step S36). If they coincide, the hop 
count update failure message is returned to the previ- 
ous hop node (step S45). If they do not coincide, the 
next flow table entry is checked (steps S37, S38). 
[0186] When the check of all the flow table entries is 
finished (step S37 YES) if the Find flag still remains 0 
(step S43 NO), the hop count update failure message is 
returned to the previous hop node (step S45). tf the Find 
flag is 1 (step S43 YES), whether the hop count in the 
received message is less than or equal to the threshold 
or not is checked (step S44), and if it exceeds the 
threshold, the hop count update failure message is 
returned to the previous hop node (step S45). If the hop 
count is less than or equal to the threshold, the Update 
flag is checked next (step S46). 
[0187] If the Update flag still remains 0, the hop count 
update success message is transmitted to the previous 
hop node (step S49). If the Update flag is 1, the 
processing for updating the ingress node information 
and the hop count in the flow table entry is carried out 
(step S47), and whether it is an egress node or not is 
checked (step S48). If it is an egress node, the hop 
count update success message is transmitted to the 
previous hop node (step S49). If it is not an egress 
node, whether the output side label exists or not is 
checked (step S50). If it exists, the hop count update 
message is transmitted to the next hop node (step S52), 
whereas if it does not exist, the label allocation mes- 
sage is transmitted to the next hop node (step S51). 
[0188] Note that in the processing for updating the 
ingress node information and the hop count in the flow 
table entry at the step S47, the decision is kept pending, 
and confirmed only when the hop count update success 
message is returned, as already described above. 
[0189] Also, in the case of not using the hop count, in 
Fig. 15, the output of the step S43 YES can be directly 
connected to the input of the step S46, and the output of 
the step S40 YES can be directly connected to the input 
of the step S42. In this case, the label allocation mes- 
sage or the update message will always be transmitted 
to the next hop node if Find = 1 and rt is not an egress 
node, so that the number of messages to be transmitted 
increases compared with the case of using the hop 
count 



[0190] The processing procedure of the node device 
at a time of receiving the label allocation success mes- 
sage, the label allocation failure message, the hop 
count update success message or the hop count update 
5 faOure message as weO as the processing procedure of 
the ing-ess node device at a time of transmitting the 
label allocation message are the same as described 
above 

[0191] Next, Fig. 16 shows another exemplary opera- 
io tion of the node device at a time of receiving the label 
allocation message in the first embodiment or the sec- 
ond embocfiment 

[0192] When the label allocation message is received, 
the fkw table entry is sequentially taken out from the top 
is of the flow table (steps S2, S3, S10, S11). When there 
is no flaw table entry, the operation proceeds to the step 
S12. 

[01 93] When it is not an ingress node (the ingress flag 
is OFF) and the input side label in the entry is the same 

20 as the label in the received message (step S4 YES), 
whether the flow ID and the ingress node information in 
the received message are the same as the values in the 
entry or not is checked (steps S1 9, S20) and when they 
alt coincide, the label allocation success message is 

25 returned to the previous hop node (step S18). Other- 
wise, the label allocation failure message is returned to 
the previous hop node (step S22). In this case, the label 
allocation message reception processing is terminated 
here. 

30 [0194] On the other hand, when it is an ingress node 
(the ingress flag is ON) or the input side label in the 
entry is different from the label in the received message 
(step S4 NO), the flow ID is checked (step S5). When 
the flow ID is Afferent, the next flow table entry is 

35 checked (steps S10, S11). When the flew ID is the 
same, whether the ingress node information is the same 
or not is checked (step S6). When the Ingress node 
information is the same, the label allocation failure mes- 
sage is returned to the previous hop node (step S22). 

40 When the ingress node information is different, the next 
flow table entry is checked (steps S10, S11). 
[0195] When the check of the flow table entry is fin- 
ished to the end (step S10 YES), the hop count in the 
received message is checked (step S12). When the hop 

45 count exceeds the threshold, the label allocation failure 
message is returned to the previous hop node (step 
S22). When the hop count is less than or equal to the 
threshold, a flow table entry is newly created (step S1 3). 
Then, if it is not an egress node (the egress flag is OFF) 

so (step S14 NO), the label allocation message is transmit- 
ted to the next hop node (step S16). If rt is an egress 
node (the egress flag is ON) (step S14 YES), the label 
allocation success message is transmitted to the previ- 
ous hop node (step S18). 

55 [0196] Rg. 16 corresponds to the protocol that also 
uses the hop count and in the case of not using the hop 
count, in Rg. 16, the step S12 can be omitted and the 
steps S2 and S1 0 can be directly connected to the step 
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S13. tn this exarrple, however, in the case off not using 
the hop count the inpjess node information must be 
used for the loop detection. 

[01 97] Note that by setting the node device off the sec- 
ond embodiment that uses the procedure of Rg. 15 
such that it does not carry out the label merging all the 
times, it can be used as the node donee (that uses the 
hop count as weO) off the first embodiment. 
[01 98] The processing procedure off the node device 
at a time off receiving the label allocation success mes- 
sage or the label allocation failure message, as well as 
the processing procedure off the ingress node device at 
a time off transmitting the label allocation message are 
the same as described above. 
[0199] The exemplary node device operation proce- 
dures described so far are directed to the case where 
the node device is separately carrying out an exclusive 
control by which the node device refuses to receive a 
message that requires a change off state from the previ- 
ous hop node while waiting for an ACK signal after the 
message transmission to the next hop node. The follow- 
ing examples are directed to the case where the node 
device carries out an exclusive control by which the con- 
sistency off states ever the entire label switched path is 
maintained at a time such as that off receiving a mes- 
sage that requires a change off state from the previous 
hop node while being in a state off waiting for ACK. In the 
following examples, as long as the node carries out the 
label merging, it is possible to realize the loop detection 
without using the ingress node information. 
[0200] The message formats to be used in the follow- 
ing examples are the same as those shown in Rg. 1 1 
and Rg. 12. 

[0201] Next, Fig. 1 7 shows another exemplary format 
off a flow table to be used at the node device on which 
the label allocation protocol off the present invention 
operates. 

[0202] The flow table registers a flow ID, an ingress 
node information (ingress node address or a set of 
ingress node address and ingress node local ID), an 
input side label (link ID, label), an output side label (link 
ID, label), a hop count an ingress flag indicating 
whether it is an ingress node or not an egress flag indi- 
cating whether it is an egress node or not and a confir- 
mation flag indicating whether the entry has been 
confirmed or not for the flow that is currently label 
switched. Note that Rg. 17 is for an exemplary case 
where the flow ID comes in one type. 
[0203] In the case of not using the ingress node infor- 
mation for the loop detection, the ingress node informa- 
tion field may be omitted, but in comparison with the 
case of using the ingress node information for the loop 
detection, there is a possfoility for the label allocation 
message and the hop count update message for the 
purpose of the loop detection to pass through more 
nodes. 

[0204] In the first and second embodiments, the 
ingress node local ID field is unnecessary. In the case off 



not using the hop count in the first embodiment the hop 
count field is unnecessary. 

[0205] The ingress flag is set by the node device cor- 
responding to the ingress node information, at a time off 

5 transmitting the label allocation message. 

[0206] The egress flag is set by the node device which 
is a destination off the flow specified by the flow ID or the 
node device whose next hop node does not support the 
label allocation protocol off the present invention, at a 

10 time off receiving the label allocation message, for 
exarrple. 

[0207] Note that each node device can learn whether 
the neighboring node device is supporting the label allo- 
cation protocol of the present invention or not by carry- 
15 ing out communications with the neighboring node 
device either in advance or as the need arises, for 
example. 

[0208] Next, Rg. 1 8 shows another exemplary opera- 
tion of the node device at a time of receiving the label 

20 allocation message in the first embodiment or the sec- 
ond embodiment This example is obtained by modify- 
ing the procedure of Rg. 14 such that always only one 
message is to be processed at a time off receiving the 
label allocation message. 

25 [0209] When the label allocation message is received, 
an Update flag that indicates the hop count update is 
cleared and a counter Cnt that indicates the number off 
flows that are merged at the own node is reset to 0 first 
(step $1-1), and the flow table entry is sequentially 

30 taken out from the top of the flow table (steps S2, S3, 
S1 0, S1 1). When there is no flow table entry, the opera- 
tion proceeds to the step S12. 
[021 0] When it is not an inp/ess node (the ingress flag 
is OFF) and the input side label in the entry is the same 

35 as the label in the received message (step S4 YES), 
whether the flow ID, the ingress node information and 
the hop count in the received message are the same as 
the values in the entry or not is checked (steps S19, 
S20, S21) and if any of them does not coincide, the 

AO label allocation failure message is transmitted to the 
previous hop node and the processing is terminated 
(step S22). 

[021 1 ] On the other hand, when they all coincide, the 
confirmation flag in the entry is checked (step S23), and 

45 H the confirmation flag is ON, the label allocation suc- 
cess message is transmitted to the previous hop node 
(step S28). whereas if the confirmation flag is OFF, 
either the received label allocation message is dis- 
carded or the label allocation failure message is trans- 

50 mitted to the previous hop node (step S24). In the case 
where the confirmation flag is OFF, the label allocation 
message reception processing is terminated here. 
[0212] On the other hand, when it is an ingress node 
(the ingress flag is ON) or the input side label in the 

55 entry is different from the label in the received message 
(step 34 NO), the flow ID is checked (step S5). When 
the flow ID is cfifferent, the next flow table entry is 
checked (steps S10, $11). When the flow ID is the 
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same, whether the ingress node information is the same 
or not is checked (step S6). When the ingress node 
information is the same, the label allocation failure mes- 
sage is returned to the previous hop node (step S22). 
[021 3] When the ingress node information is different, 
if the label merging is supported (step S7 YES), the 
counter Cnt is incremented by one (step S1-2) and if 
also the hop count in the received message is greater 
than the hop count in the entry (steps S8 YES), whether 
the confirmation flag is ON or not is checked (step 
S200). tf the confirmation flag is ON, the Update flag is 
set (step S9), and the next flow table entry is checked 
(steps S10, S11). If the confirmation flag is OFF, the 
label allocation message is transmitted to the previous 
hop node and the processing is terminated (step S22). 
In the case where the label merging is not supported or 
the hop count in the received message is less than or 
equal to the hop count in the entry (step S7 NO or S8 
NO), the next flow table entry is checked (steps S10, 
S1 1) while leaving the Update flag unchanged. 
[0214] When the check of the flow table entry is fin- 
ished to the end (step S10 YES), the hop count in the 
received message is checked (step S12). When the hop 
count exceeds the threshold, the label allocation failure 
message is returned to the previous hop node (step 
S22). When the hop count is less than or equal to the 
threshold, a flow table entry is newly created (step S13). 
Then, if it is an egress node (the egress flag is ON) (step 
S14 YES), the confirmation flag is turned ON and the 
label allocation success message is transmitted to the 
previous hop node (step S18). 
[0215] If it is not an egress node (the egress flag is 
OFF) (step S14 NO), the Update flag is checked (step 
S15), and when the Update flag is ON, the confirmation 
flag is turned OFF and the hop count update message 
is transmitted to the next hop node (step S27). When 
the Update flag is OFF, if cnt = 0 (the own node is not 
the merging point) (step S25 NO), the confirmation flag 
is turned OFF and the label allocation message is trans- 
mitted to the next hop node (step S26), whereas if cnt = 
1 (the own node is the merging point) (step S25 YES), 
the confirmation flag is turned ON (the merging setting 
is made) and the label allocation success message is 
transmitted to the previous hop node (step S28). In the 
case where the Update flag is OFF and Cnt = 0, the 
label allocation success message may also be transmit- 
ted to the previous hop node in addition to the above 
operation at the step S26. 

[021 6] Note that in the creation of the flow table entry 
at the step S1 3, the decision is kept pending (the confir- 
mation flag is set OFF), and confirmed only when the 
label allocation success message is returned, as 
already descrfoed above (the confirmation flag is set 
ON). 

[0217] Also, in the case of not using the ingress node 
information for the loop detection, in Fig. 18, the output 
of the step S5 YES can be directly connected to the 
input of the step S7, and the output of the step S1 9 YES 



can be directly connected to the input of the step S21. tn 
this case, in comparison with the case of using the 
ingress node information for the loop detection, the 
label allocation message and the hop count update 
5 message for the purpose of the loop detection will pass 
through more nodes. 

[0218] Also, in the case of not using the hop count, in 
Fig. 1 8, the output of the step S1 -2 YES can be directly 
connected to the input of the step S200, the output of 

10 the step S2 NO and the output of the step S10 YES can 
be directly connected to the input of the step S13, and 
the output of the step S20 YES can be directly con- 
nected to the input of the step S23. tn this case, the hop 
count update message will always be transmitted to the 

is next hop node from the merging point if it is not an 
egress node, so that the number of messages to be 
transmitted increases compared with the case of using 
the hop count 

[0219] tn the case where every node in the network 
20 supports the label merging, it is also possible not to use 
both the ingress node information and the hop count tn 
this case, the flow chart for the operation becomes the 
common part of the flow chart for the case of not using 
the ingpess node information for the loop detection and 
25 the flow chart for the case of not using the hop count, 
which is as shown in Fig. 19. 

[0220] Next, Fig. 20 shows another exemplary opera- 
tion of the node device at a time of receiving the hop 
count update message in the second embodiment This 
30 example is obtained by modifying the procedure of Fig. 
15 such that always only one message is to be proc- 
essed at a time of receiving the hop count update mes- 
sage. 

[0221] When the hop count update message is 

35 received, a Find flag is set to 0 and an Update flag is set 
to 1 (step S3 1-1), and the flow table entry is sequentially 
taken out from the top of the flow table (steps S32, S33, 
S37, S38). When there is no flew table entry, the hop 
count update failure message is returned to the previ- 

40 ous hop node (step S65-2). 

[0222] When it is not an ingress node (the ingress flag 
is OFF) and the input side label in the entry is the same 
as the label in the received message (step S34 YES), 
the Find flag is set to 1 (step S39), and whether the flow 

45 ID in the received message is the same as the value in 
the entry a not is checked (step S40), and if they do not 
coincide, the hop count update failure message is 
returned to the previous hop node and the processing is 
terminated (step S65-2). If they coincide, whether the 

so hop count is the same as the value in the entry or not is 
checked (step S41), and if the hop count is the same, 
whether the ingress node information is the same or not 
is checked (step S63). 

[0223] tf the ingress node information is the same, the 
55 confirmation flag is turned ON and the hop count update 
success message is transmitted to the previous hop 
node (step S69). tf the hop count is different or the 
ingress node information is different the confirmation 
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flag in the entry is checked (step S64), and if the confir- 
mation flag is ON. the next flow table entry is checked 
(steps S37, S38). If the confirmation flag is OFF, either 
the received message is discarded or the hop count 
update failure message is transmitted to the previous 5 
node and the processing is terminated (step S65-1). 
[0224] On the other hand, when it is an ingress node 
(the ingress flag is ON) or the input side label in the 
entry is different from the label in the received message 
(step S34 NO), whether the flow ID in the received mes- w 
sage is the same as the value in the entry or not is 
checked (step S35), and if they do not coincide, the next 
flow table entry is checked (steps S37, S38). if they 
coincide, whether the ingress node information in the 
received message is the same as the value in the entry 75 
or not is checked (step S36). If they coincide, the hop 
count update failure message is returned to the previ- 
ous hop node (step S65-2). If they do not coincide, 
whether the confirmation flag is OFF or not is checked 
(step S201 ), and if the confirmation flag is OFF, the next 20 
flow table entry is checked (steps S37, S38) whereas if 
the confirmation flag is ON, the Update flag is cleared to 
0 (step S202) and the next flow table entry is checked 
(steps S37, S38). 

[0225] When the check of all the flow table entries is 25 
finished (step S37 YES), if the Find flag still remains 0 
(step S43 NO), the hop count update failure message is 
returned to the previous hop node (step S65-2). If the 
Find flag is 1 (step S43 YES), whether the hop count in 
the received message is less than or equal to the so 
threshold or not is checked (step S44), and if it exceeds 
the threshold, the hop count update failure message is 
returned to the previous hop node (step S65-2). If the 
hop count is less than or equal to the threshold, the 
Update flag is checked next (step S46). 35 
[0226] If the Update flag stall remains 0, the confirma- 
tion flag is turned ON and the hop count update success 
message is transmitted to the previous hop node (step 
S69). If the Update flag is 1 , the processing for updating 
the ingress node information and the hop count in the 40 
flow table entry is carried out (step S67), and whether it 
is an egress node or not is checked (step S48). If it is an 
egress node, the confirmation flag is turned ON and the 
hop count update success message is transmitted to 
the previous hop node (step S69). If it is not an egress 45 
node, whether the output side label exists or not is 
checked (step S50). If it exists, the confirmation flag is 
turned OFF and the hop count update message is 
transmitted to the next hop node (step S72), whereas if 
it does not exist the confirmation flag is turned OFF and so 
the label allocation message is transmitted to the next 
hop node (step S71). 

[0227] Here, the node other than the ep/ess node may 
transmit the hop count update success message to the 
previous hop node while executing the step S71 or S72 ss 
in the case where the updated hop count value 
becomes less than the value before the updata 
[0228] Note that in the processing for updating the 



ingress node in forma tion and the hop count in the flow 
table entry at the step S67, the decision is kept pending, 
arid confirmed only when the hop count update success 
message is returned, as already descrfced above. 
[0229] Also, in the case of not using the ingress node 
information for the loop detection, in Fig. 20, the output 
of the step S35 YES can be directly connected to the 
input of the step S201, and the output of the step S41 
YES can be directly connected to the input of the step 
S69. In this case, in comparison with the case of using 
the ingress node information for the loop detection, the 
label allocation message and the hop count update 
message for the purpose of the loop detection will pass 
through more nodes. 

[0230] Also, in the case of not using the hop count, in 
Rg. 20, the output of the step S43 YES can be directly 
connected to the input of the step S46, and the output of 
the step S40 YES can be directly connected to the input 
of the step S64 (as a result the step S63 is omitted). 
Also, the message to be transferred through a portion 
after the merging point where the label switched path 
already exists may be given in a form of "update mes- 
sage" without containing the hop count. In this case, the 
label allocation message or the hop count update mes- 
sage wiD always be transmitted to the next hop node if 
Find = 1 and it is not an egress node, so that the number 
of messages to be transmitted increases compared with 
the case of using the hop count. 
[0231 ] In the case where every node in the network 
supports the label merging, it is also possible not to use 
both the ingress node information and the hop count. In 
this case, the flow chart for the operation becomes the 
common part of the flow chart for the case of not using 
the ingress node information for the loop detection and 
the flow chart for the case of not using the hop count, 
which is as shown in Rg. 21 . 
[0232] The processing procedure of the node device 
at a time of receiving the label allocation success mes- 
sage, the label allocation failure message, the hop 
count update success message or the hop count update 
failure message as well as the processing procedure of 
the ingress node device at a time of transmitting the 
label allocation message are the same as descrfoed 
above. 

[0233] Next, Rg. 22 shows another exemplary opera- 
tion of the node device at a time of receiving the label 
allocation message in the first embodiment or the sec- 
ond embodiment. This example is obtained by modify- 
ing the procedure of Rg. 16 such that always only one 
message is to be processed at a time of receiving the 
label allocation message. 

[0234] When the label allocation message is received, 
the flow table entry is sequentially taken out from the top 
of the flow table (steps S2, S3, S10, S1 1). When there 
is no flow table entry, the operation proceeds to the step 
S12. 

[0235] When it is not an ingress node (the ingress flag 
is OFF) and the input side label in the entry is the same 
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as the label in the received message (step S4 YES), 
whether the flow ID and the ingress node information in 
the received message are the same as the values in the 
entry or not is checked (steps S1 9, S20) and when they 
all coincide, whether the confirmation flag is ON or not 
is checked (step S23). If the confirmation flag is OFF, 
either the received message is discarded or the label 
allocation failure message is transmitted to the previous 
hop node (step S24). rf the confirmation flag is ON, the 
label allocation success message is returned to the pre- 
vious hop node (step S28). K the flow ID is different or 
the ingress node information is different, the label allo- 
cation failure message is returned to the previous hop 
node (step S22). In this case, the label allocation mes- 
sage reception processing is terminated hera 
[0236] On the other hand, when it is an ingress node 
(the ingress flag is ON) or the input side label in the 
entry is different from the label in the received message 
(step S4 NO), the flow ID is checked (step S5). When 
the flow ID is different, the next flow table entry is 
checked (steps S10. S11). When the flow ID is the 
same, whether the ingress node information is the same 
or not is checked (step S6). When the ingress node 
information is the same, the label allocation failure mes- 
sage is returned to the previous hop node (step S22). 
When the ingress node information is different, the next 
flow table entry is checked (steps S10, S1 1). 
[0237] When the check of the flow table entry is fin- 
ished to the end (step S10 YES), the hop count in the 
received message is checked (step S12). When the hop 
count exceeds the threshold, the label allocation failure 
message is returned to the previous hop node (step 
S22). When the hop count is less than or equal to the 
threshold, a flow table entry is newly created (step S1 3). 
Then, if it is not an egress node (the egress flag is OFF) 
(step S14 NO), the confirmation flag is turned OFF and 
the label allocation message is transmitted to the next 
hop node (step S26). If it is an egress node (the egress 
flag is ON) (step S14 YES), the confirmation flag is 
turned ON and the label allocation success message is 
transmitted to the previous hop node (step S18). 
[0238] Fig. 22 corresponds to the protocol that also 
uses the hop count and in the case of not using the hop 
count, in Fig. 22, the step S12 can be omitted and the 
steps S2 and S1 0 can be directly connected to the step 
S13. In this example, however, in the case of not using 
the hop count the ingress node information must be 
used for the loop detection. 

[0239] Note that by setting the node device of the sec- 
ond embodiment that uses the procedure of Fig. 20 
such that it does not cany out the label merging all the 
times, it can be used as the node device (that uses the 
hop count as well) of the first embodiment 
[0240] The processing procedure of the node device 
at a time of receiving the label allocation success mes- 
sage or the label allocation failure message, as well as 
the processing procedure of the ingress node device at 
a time of transmitting the label allocation message are 



the same as described abova 
[0241] Next the operation of the node device in the 
case of releasing the label switched path whfle the 
merging is possble will be described. In the case of 

5 releasing the label switched path, the node device 
transmits a label release message" to the next hop 
node. Then, upon receiving a label release success 
message" from the next hop node, the node that trans- 
mitted the "label release message" deletes the corre- 

10 sponding flow table entry. 

[0242] Fig. 23 shows an exemplary operation of the 
node device at a time of receiving the label release 
message in the first embodiment or the second embod- 
iment 

is [0243] In Fig. 23, Ed is a variable for indicating a flow 
table entry corresponding to the received label release 
message, Eu is a variable for indicating a flow table 
entry that gives the maximum hop count from the 
inyess node after the entry Eu is deleted, and hmax is 

20 a variable for indicating the maximum hop count value 
from the ingress node after the entry Ed is deleted. 
[0244] When the label release message is received, 
Ed and Eu are initialized to NIL and hmax is initialized to 
0 (step S101), and the flow table entry is sequentially 

25 taken out from the top of the flow table (steps S102, 
S103, S1 10. S1 1 1). When there is no flow table entry, 
the label release success message is returned to the 
previous hop node (step S116). 
[0245] Fa each flow table entry, the following process- 
so ing is carried out. First, whether the input side label is 
the same as the label value in the received message or 
not is checked (step S104), and if it is the same, 
whether the flow ID and the ingress node information in 
the received message are the same as the values in the 

35 entry or not is checked (steps S1 19, S120). ff either one 
of them does not coincide, the label release failure mes- 
sage is transmitted to the previous hop node and the 
processing is terminated (step S122), whereas if both 
the flow ID and the ingress node information are the 

40 same as the values in the entry, Ed is set equal to this 
entry (step S121), and the next flow table entry is 
checked (steps S1 10, S1 1 1). 
[0246] On the other hand, when the input side label 
differs from the label value in the received message, 

45 whether the flow ID in the message is the same as the 
value in the entry or not is checked (step S105). When 
the flow ID is cfifferent the next flow table entry is 
checked (steps S110, S111). When the flow ID is the 
same, whether the ingress node information in the mes- 

so sage is the same as the value in the entry or not is 
checked (step S106). When the ingress node informa- 
tion is the same, the label release failure message is 
transmitted to the previous hop node and the process- 
ing is terminated (step S122). 

55 [0247] When the ingress node information is different, 
whether this node supports the label merging or not is 
checked (step S107), and if the label merging is not 
supported, the next flow table entry is checked (steps 
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S110, S111). If the label merging is supported, when 
hmax is greater than the hop count of this entry (step 
S108 NO), the next flow table entry is checked (steps 
S1 10. S111). whereas when hmax is less than or equal 
to the hop count of this entry (step S108 YES), Euisset 5 
equal to this entry and hmax is set equal to the hop 
count of this entry (step S109) and the next flow table 
entry is checked (steps S1 10, S111). 
[0248] When the check of the flow table entry is fin- 
ished (step S1 1 0 YES), the label release success mes- 10 
sage is transmitted to the previous hop node (step 
S128). Then, the processing is terminated if Ed is NIL 
(step S1 16 YES), or otherwise whether Eu is NIL or not 
is checked (step S117). If Eu is NIL, the confirmation 
flag of Ed is turned OFF and the label release message is 
is transmitted to the next hop node and then the 
processing is terminated (step S126). tf Eu is not NIL, 
when hmax is greater than the hop count in the entry Ed 
(step S118 NO), the processing is terminated, and 
when hmax is less than or equal to the hop count in the so 
entry Ed (step S1 1 8 YES), the confirmation flag of Eu is 
turned OFF and the hop count update message is 
transmitted to the next hop node and then the process- 
ing is terminated (step S127). 

[0249] Here, the values in the entry Eu are written into 2s 
the hop count and the ingress node information in the 
hop count update message to be transmitted. 
[0250] Note that when the node receives the label 
release success message (the label release failure 
message) with respect to some output side label, this 30 
node deletes that entry if the confirmation flag in the 
flow table entry for that output side label is OFF. 
[0251] By the above processing, it becomes possble 
to maintain the updated ingress node information and 
hop count value correctly after the label release at each 35 
node, even in the case where the ingress node that 
gives the maximum hop count value among the 
upstream side nodes changes, and it becomes posstole 
to carry out the loop detection even in the case where 
the label switched path generation and release occur 40 
asynchronously. 

[0252] Note that, in the case of not using the ingress 
node information for the loop detection, in Fig. 23, the 
output of the step S105 YES can be cfirectly connected 
to the input of the step S107, and the output of the step 45 
S1 19 YES can be directly connected to the input of the 
step S1 21. 

[0253] Also, in the case of not using the hop count in 
Fig. 23. the processing at the step S109 can be modi- 
fied to just setting Eu equal to this entry by omitting the so 
operation for setting hmax equal to the hop count of this 
entry, while the output of the step S107 YES can be 
directly connected to the input of the step S109 as mod- 
ified above, and the output of the step S1 17 NO can be 
directly connected to the input of the step S1 27. In this ss 
case, the number of messages to be transmitted 
increases compared with the case of using the hop 
count 



[0254] Note that, in the case of carrying out the loop 
detection by writing the ingress node information of arbi- 
trary flow table entry with respect to the flow of interest 
which has the common output side label into the hop 
count update message and transmitting such a hop 
count update message, the label switched path release 
procedure can be realized similarty as in the case of not 
using the hop count 

[0255] In the case where every node in the network 
supports the label merging, it is also possible not to use 
both the ingress node information and the hop count In 
this case, the flow chart for the operation becomes the 
common part of the flow chart for the case of not using 
the ingress node information for the loop detection and 
the flow chart for the case of not using the hop count, 
which is as shown in Fig. 24. 
[0256] Note that the procedures of Fig. 14, Fig. 15 and 
Fig. 16 are those to which the modification for not using 
the confirmation flag is applied to the procedures of Fig. 
18, Fig. 20 and Fig. 22, respectively, and it is similarly 
possfcle to apply the modification for not using the con- 
firmation flag to the procedure of Fig. 23. It is also pos- 
sible to apply the modification for not using the 
confirmation flag to the procedure of Fig. 23 which is 
also modified not to use the hop count 
[0257] Next an exemplary case of carrying out the 
label switched path loop detection of the above 
described embodiments in the case of multicast will be 
described. In the case of multicast the label merging is 
not carried out and the label switched path is set up by 
the initiative of the ingress node. The packet format is 
the same as in the case of unicast, and the label can be 
allocated at either the upstream side node or the down- 
stream side node. 

[0258] For the flow ID, the multicast gjoup address is 
used when the multicast routing table entry is provided 
for each multicast group address, or a set of the source 
address and the multicast group address is used when 
the multicast routing table entry is provided for each set 
of the source address and the multicast group address. 
[0259] The flow table format in the case of not using 
the confirmation flag is similar to that of Fig. 13 except 
that the output side label field is replaced by one or 
more output side label fields corresponding to output 
branches of the multicast at the own node. 
[0260] The flow table format in the case of using the 
confirmation flag is similar to that of Fig. 17 except that 
the output side label field is replaced by one or more 
output side label fields corresponding to output 
branches of the multicast at the own node. 
[0261] Next, the operation at a time of the label 
switched path generation in the case of multicast will be 
described. 

[0262] First the ingress node transmits the label allo- 
cation message to each output branch of the multicast 
at the own node, at a time of activating the label 
switched path generation. 

[0263] In the case of not using the confirmation flag, 
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the node that received the label allocation message 
operates simOarty as in the case of unicast according to 
the flow chart of Fig. 16, except that the step S1 6 of Rg. 
16 is changed to the step for transmitting the label allo- 
cation message to each output branch of the multicast s 
at the own node. 

[0264] In the case of using the confirmation flag, the 
node that received the label allocation message oper- 
ates similarly as in the case of unicast according to the 
flow chart of Fig. 22, except that the step S26 of Fig. 22 10 
is changed to the step of turning the confirmation flag 
OFF and transmitting the label allocation message to 
each output branch of the multicast at the own noda 
[0265] On the other hand, at the node that received 
the label allocation success message or the label alb- is 
cation failure message from the downstream side neigh- 
boring node of each branch of the multicast at the own 
node, any one of the following operations is carried out 

(1) When the label allocation success messages 20 
are received from the downstream side neighboring 
nodes of all the branches, the label allocation suc- 
cess message is returned to the upstream side 
neighboring node, whereas when the label alloca- 
tion failure message is received from the down- 25 
stream side neighboring node of at least one 
branch, the label allocation failure message is 
returned to the upstream side neighboring node. (If 

it is possible to form the label switched paths end- 
to-end for all the branches, the label switched paths 30 
to aD the multicast receivers are set up) 

(2) The label allocation success message is always 
returned to the upstream side neighboring node. 
(Regardless of the downstream side, the label 
switched path from the sender up to the own node 35 
is set up.) 

(3) When the label allocation success message is 
received from the downstream side neighboring 
node of at least one branch, the label allocation 
success message is returned to the upstream side 40 
neighboring node, whereas when the label alloca- 
tion failure messages are received from the down- 
stream side neighboring nodes of all the branches, 
the label allocation failure message is returned to 
the upstream side neighboring noda (If it is possi- 45 
ble to form the label switched path end-to-end for 
some branch, the label switched path from the 
sender to that receiver is set up) 

[0266] Next, the operation at a time of the label so 
switched path release in the case of multicast will be 
descrbed. 

[0267] First, the node that activates the label switched 
path release transmits the label release message to 
each output branch of the multicast at the own noda 55 
[0268] In the case of using the hop count the node 
that received the label release message operates simi- 
larly as in the case of unicast according to the flow chart 



of Fig. 23, except that the step S126 of Fig. 23 is 
changed to the step of turning the confirmation flag of 
Ed OFF and transmitting the label release message to 
each output branch of the multicast at the own node. 
Ateo, in this case, there is no possbOrty for the step 
S117NO. 

[0269] In the case of not using the hop count the node 
that received the label release message operates simi- 
larly as in the case of unicast according to the flow chart 
of Fig. 24. except that the step S126 of Fig. 24 is 
changed to the step of turning the confirmation flag of 
Ed OFF and transmitting the label release message to 
each output branch of the multicast at the own node. 
Also, in this case, there is no posstoflrty for the step 
St 17 NO. 

[0270] Also, the node that received the label release 
success message from the downstream side neighbor- 
ing nodes of aD the branches of the multicast at the own 
node win delete the flw table entry. 
[0271] The embodiments described above are 
directed to the case where the label allocation message 
is transmitted from the ingress node toward the next hop 
node, and the label allocation success/failure message 
is transmitted from the egress node toward the previous 
hop node (i.e., the case of Ingress control), but the 
present invention is also applicable to the case where 
the label allocation message is transmitted from the 
egress node toward the previous hop node, and the 
label allocation success/failure message is transmitted 
from the ingress node toward the next hop node (i.e., 
the case of Egress control). 

[0272] Note that in the various embodiments of the 
Ingress control type descrtoed above, it is also possfole 
to realize the loop detection by transmitting the update 
message for the purpose of the loop detection in a 
direction opposite to that of the path. 
[0273] In this case, the node that is supposed to trans- 
mit the update message upon receiving the label alloca- 
tion message is going to transmit a "query message** to 
the node that transmitted the label allocation message, 
instead of transmitting the update message to the 
downstream side neighboring node, and turns the con- 
firmation flag OFF. 

[0274] The node that received the query message 
transmits the update message to each upstream side 
neighboring node for which the input side label exists, 
and turns the confirmation flag OFF. The update mes- 
sage is then successively forwarded to the upstream 
side neighboring nodes for which the input side label 
exists, and when the node with the confirmation flag 
OFF receives the update message, it is judged that 
there is a loop and the update failure message is 
returned. On the other hand, in the case where the con- 
firmation flag is ON when the ingress node receives the 
update message, the update success message is 
returned. When the update failure message is received 
from at least one upstream side neighboring node, the 
update failure message is returned to the downstream 
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side neighboring nodes, or otherwise the update suc- 
cess message is returned. In either case the confirma- 
tion flag is turned ON. 

[0275] When the node that initially transmitted the 
update message receives the update failure message, s 
the query failure message is transmitted to the down- 
stream side neighboring nodes, and whereas when the 
node that initially transmitted the update message 
receives the update success message, the query suc- 
cess message is transmitted to the downstream side 
neighboring nodes. In either case the confirmation flag 
is turned ON. The node that receives the query success 
message becomes capable of carrying out the label 
switching, whereas the node that received the query 
failure message deletes the input side label. In either 
case the confirmation flag is turned ON. 
[0276] For example, in Fig. 5, when the node device 
R5 transmitted the label allocation message to the node 
device R2, the node device R2 transmits the query mes- 
sage to the node device R5 and turns the confirmation 
flag OFF. Upon receiving the query message from the 
node device R2, the node device R5 transmits the 
update message to the node device R4 and turns the 
confirmation flag OFF. The update message is then for- 
warded from the node device R4tothe node device R3, 
from the node device R3 to the node devices R2 and 
R8, from the node device R8 to the node device R7, and 
from the node device R7 to the node device R6. When 
the node device R2 receives the update message, it is 
judged that there is a loop because the confirmation flag 
is already OFF, and the update failure message is 
returned to the node device R3. The node device R6 
transmits the update success message, which is for- 
warded up to the node device R3. The node device R3 
transmrts the update failure message to the node device 
R4, which is forwarded up to the node device R5. Upon 
receiving the update failure message, the node device 
R5 returns the query failure message to the node device 
R2, so that the label switching is not carried out 
between the node device R2 and the node device R5. 
[0277] The query message and the query success 
message has a format similar to that of Fig. 11, while 
the query failure message has a format similar to that of 
Fig. 12, except that the label value is specified in these 
messages. 

[0278] Note also that the description up to now pre- 
supposes the hard state type protocol in which the label 
allocation message is not transmitted to the path to 
which the label is allocated once, but the present inven- 
tion is also effective for the soft state type protocol in 
which the label allocation message is transmitted regu- 
larly even for the path to which the label is allocated 
once. In the case of the soft state type protocol, the 
label is released when the label allocation message is 
not received for a preserved period of time. 



(Fourth Embodiment) 

[0279] Up to this point the loop detection method in 
the case of setting up the label switched path by the ini- 
tiative of the ingress node has been described. Now, the 
loop detection method in the case of setting up the label 
switched path by the initiative of the egress node win be 
described. 

[0280] Here, the method for setting up the label 
switched path by the initiative of the egress node is basi- 
cally the method disclosed in N. Fekfman and A. Viswa- 
nathan, "ARIS Specification", Internet Draft (work in 
prog-ess), draft-feldman-aris-soec-00.txt March 1997, 
but the loop detection method is different from this refer- 
ence in that the path vector that is a list of nodes on the 
path is not used so that the message length can be 
shortened compared with the case of using the path 
vector. 

[0281] In the following description, the basic issues 
related to the node device, such as the fact that the 
node device has a function for carrying out the IP 
processing as well as a function for carrying out the 
label switching accord ng to the label allocation protocol 
according to the present invention, the terms such as 
the ingress node information, the flow ID, the link ID, the 
interface ID, the input side label, and the output side 
label and their definitions, etc., are basically the same 
as those of the first and second embodiments described 
above. 

[0282] As for the timing at which the node device 
transmrts the label allocation message as an egress 
node, the following options are available, for example. 

(1) The label allocation message is transmitted at a 
timing where each node device that is registered as 
an egress is activated. 

(2) The label allocation message is transmitted at a 
timing where the amount of passing traffics of the 
flow at each node device that is registered as an 
egress (the packet flow that passes through each 
node that is registered as an egress) exceeds a 
threshold. 

(3) Only a node that satisfies a condition that the 
amount of traffics for the flow (the packet flow that 
passes through each node that is registered as an 
egress) exceeds a threshold and the next hop node 
for the flow does not support the label allocation 
protocol according to the present invention, judges 
the own node as an egress at this timing and trans- 
mits the label allocation message. 

[0283] Examples of nodes that can be registered as 
egress include an area border router of OSPF, a domain 
boundary router, and a neighbor BGP router. 
[0284] Note that in the case of (3) described above, a 
node registered as an egress and a node that actually 
becomes an egress of the label switched path will be 
different 
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[0285] Now, in the case of generating the label 
switched path by the initiative of the egress node 
(Egress control), the process for label allocation is acti- 
vated from the egress node with respect to aD the 
upstream side neighboring nodes, and when the proc- 
ess for label allocation is activated from the next hop 
node of the flow, each node other than the egress node 
activates he process for label allocation with respect to 
the further upstream side neighboring nodes (the neigh- 
boring nodes other than the next hop node). Eventually, 
when the process for label allocation is activated at the 
ingress node, the label switched path from the ingress 
node to the egress node is formed. This process is 
called an initial generation process. At this point the 
label switched path has a tree-like shape with the 
ingress node as a leaf and the egress node as a root 
[0286] Note that if the route change does not occur at 
a node that is executing the process for label allocation 
during the initial generation process, the above process 
guarantees that there is no loop because the path is 
formed sequentially from the exit of the path (because 
the existence of the exit of the path is guaranteed). 
[0287] However, in the case of releasing the label allo- 
cation at the already existing output side and carrying 
out the label allocation with a new next hop node due to 
the route change or the other cause, matte, in the case 
of newly allocating the output side label while the input 
side label exists, a loop will be formed if the own node is 
located on the downstream side of the new next hop 
node so that there is a need to check that the wn node 
is not located at the downstream side of the new next 
hop node before the label allocation with the new next 
hop node is carried out 

[0288] For this reason, in the case of newly allocating 
the output side label while the input side label exists at 
some node, the message for the loop detection is trans- 
mitted to the downstream side node while setting the 
confirmation flag OFF, and it is judged that there is a 
loop when this message is received from the upstream 
side node while the confirmation flag is OFF. Otherwise 
when this message reaches to the egress node, it is 
judged that there is no loop. In the case of using the 
ingress node information and the hop count from the 
ingress node for the purpose of the loop detection, it is 
possible to detect a loop before the message for the 
loop detection goes around the loop once. 
[0289] For the message for loop detection, the update 
message is used. The update message is used not only 
for the purpose of the loop detection, but also for the 
purpose of notifying the change of a path state to the 
downstream side node. 

[0290] In this fourth embodiment, the case of using 
the number of hops from the egress node as the hop 
count will be descrfoed, but the hop count may be omit- 
ted. The examples described below are all directed to 
the operation regarding a flow with a certain Flowid = 
Egress [R1] (a packet stream having R1 as an egress 
node). 



[0291] Note that, in this fourth embodiment the node 
address (R1 in the notation of Flowid - Egress [R1]) to 
be used for identifying the flow coincides with the node 
that actually becomes the egress of the label switched 

5 path, but in general, the node address to be used for 
identifying the flow may not necessarily coincide with 
the actual egress node of the label switched path. For 
example, in Fig. 25 which win be descrbed in detail 
below, a node R0 (not shown) that is registered as an 

10 egress may exist as a next hop node of the node R1 , in 
which case Flowid = Egress [R0] win be used, but the 
actual egress node of the label switched path is the 
node R1. 

[0292] Now, some exemplary cases of setting up the 
is label switched path by the initiative of the egress node 
will be described. 

[0293] First the method not using the ingress node 
information will be descrbed. For the sake of simplicity, 
it is assumed that every node is capable of carrying out 

20 the label merging. The case of not carrying out the label 
merging will be described later. Also, it is assumed that 
each node carries out the label allocation by the initia- 
tive of the downstream side (Downstream label alloca- 
tion), but the label allocation by the initiative of the 

26 upstream side (Upstream label allocation) is equally 
possftxe. 

[0294] Initially, every node initializes the confirmation 
flag to ON state. 

[0295] The egress node transmits the label allocation 
30 message in which the hop count = 1 is specified to all 
the upstream side neighboring nodes (neighboring 
nodes other than the next hop node) of the flow. 
[0296] When the output side label for that flow is set 
up, the node other than the e&ess node transmits the 
35 label allocation message in which the hop count 
obtained by incrementing the hop count received from 
the egress node by one is specified to aD the upstream 
side neighboring nodes (neighboring nodes other than 
the next hop node) of the flow. For those upstream side 
40 neighboring nodes for which the input side label does 
not exist the label allocation message is transmitted 
regularly. 

[0297] A node U that received the label allocation 
message returns the label allocation failure message if 

45 a message source node D is not a next hop node for 
that flow, or if the received hop count exceeds the 
threshold, or if the confirmation flag is OFF, or if it is the 
egress node itself. When none of these conditions 
holds, if the output side label does not exist despite that 

so the input side label exists, the confirmation flag is turned 
OFF and a "query message" is transmitted to the node 
D. Otherwise, the label allocation success message is 
transmitted to the node D. At this point, rf the output side 
label does not exist the allocation of the output side 

55 label is carried out and the hop count in the message is 
stored as the hop count from the egress noda 
[0298] The node that received the label allocation suc- 
cess message from the upstream side neighboring 
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node becomes capable of carrying out the label switch- 
ing between the input side label and the output side 
label thereafter, unless it is the egress node itself. 
[0299] The node that received the label allocation fail- 
ure message quits the registration of the input side s 
label. 

[0300] In the case where the route change or the route 
deletion occurs at a node U on the path, the node U 
transmits the label release message to a next hop node 
Dold of an old route, and turns the confirmation flag w 
OFF. 

[0301] The node Dold that received the label release 
message transmits the label release success message 
to the node U and releases the label. 
[0302] The node U that received the label release sue- 75 
cess message turns the confirmation flag ON, and if 
there is a next hop node Dnew of a new route, transmits 
a label allocation trigger message to the node Dnew. 
The label allocation trigger message is regularly re- 
transmitted until the label allocation message is 20 
received from the node Dnew. 
[0303] The node Dnew that received the label alloca- 
tion trigger message returns to the node U the label 
allocation message in which the hop count obtained by 
incrementing the hop count from the egress node to the 2s 
own node by one is specified, if the confirmation flag is 
ON and either it is the egress node HseH or the output 
side label exists. 

[0304] The node D that received the query message 
from the node U returns the query failure message to 30 
the node U if the confirmation flag is OFF, and does not 
carry out the registration of the input side label. When 
the confirmation flag is not OFF, if the output side label 
exists, the update message is transmitted to the down- 
stream side neighboring node, and the confirmation flag 35 
is turned OFF. Otherwise, the query success message 
is transmitted to the node U. 

[0305] The node that received the update message 
from the upstream side neighboring node returns the 
update failure message if the confirmation flag is OFF. ao 
When the confirmation flag is not OFF, rf the output side 
label exists, the update message is transmitted to the 
downstream side neighboring node, and the confirma- 
tion flag is turned OFF. Otherwise, the update success 
message is returned. as 
[0306] The node that received the update success 
message from the downstream side neighboring node 
turns the confirmation flag ON, and returns the update 
success message to the upstream side neighboring 
node that transmitted the update message while trans- so 
miffing the query success message to the upstream 
side neighboring node that transmitted the query mes- 
sage. 

[0307] The node that received the update failure mes- 
sage from the downstream side neighboring node turns ss 
the confirmation flag ON, and returns the update failure 
message to the upstream side neighboring node that 
transmitted the update message while transmitting the 



query failure message to the upstream side neighboring 
node that transmitted the query message. 
[0308] The node U that received the query success 
message from the node D registers the output side label 
and turns the confirmation flag ON. Thereafter, the label 
switching between the input side label and the output 
side label becomes possible. 
[0309] The node U that received the query failure 
message from the node D turns the confirmation flag 
ON. Thereafter, the label switching between the input 
side label and the output side label is not carried out 
[0310] Next, with reference to Fig. 25, the exemplary 
operation at a time of the label switched path generation 
will be described. In Fig. 25, it is assumed that R1 is the 
egress node, ft is also assumed that the next hop nodes 
of R2, R3, R4, R5 and R6 are respectively R1, R2, R3, 
R2andR2. 

[031 1 ] The node device R1 transmits the label alloca- 
tion message ml (Flowid = Egress [R1], Label = a, Hop- 
count = 1) to the node device R2. 
[0312] Upon receiving the label allocation message 
ml from the node device R1 , the node device R2 stores 
Label = a and returns the label allocation success mes- 
sage to the node device R1 because the node device 
R1 is the next hop node of this flow and the confirmation 
flag is ON. Then, the node device R2 transmits the label 
allocation messages m2 (Flowid = Egress [R1], Label = 
b, Hopcount = 2), m3 (Flowid = Ecpess [R1], Label = c, 
Hopcount = 2), and m4 (Flowid = Egress [R1], Label = 

d, Hopcount = 2) to the node devices R5, R3 and R6, 
respectively, which are the neighboring nodes other 
than the next hop node. 

[0313] Upon receiving the label allocation message 
m2 from the node device R2, the node device R5 stores 
Label = b and returns the label allocation success mes- 
sage to the node device R2 because the node device 
R2 is the next hop node of this flow and the confirmation 
flag is ON. Then, the node device R5 transmits the label 
allocation messages m7 (Flowid = Egress [R1], Label = 
g, Hopcount = 3) to the node device R4 which is the 
neighboring node other than the next hop noda 
[0314] Upon receiving the label allocation message 
m3 from the node device R2, the node device R3 stores 
Label = c and returns the label allocation success mes- 
sage to the node device R2 because the node device 
R2 is the next hop node of this flow and the confirmation 
flag is ON. Then, the node device R3 transmits the label 
allocation messages m5 (Florid = Egress [R1], Label = 

e, Hopcount = 3) to the node device R4 which is the 
neighboring node other than the next hop noda 
[0315] Upon receiving the label allocation message 
m4 from the node device R2, the node device R6 stores 
Label = d and returns the label allocation success mes- 
sage to the node device R2 because the node device 
R2 is the next hop node of this flow and the confirmation 
flag is ON. 

[0316] Upon receiving the label allocation message 
m5 from the node device R3, the node device R4 stores 
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Label = e and returns the label allocation success mes- 
sage to the node device R3 because the node device 
R3 is the next hop node of this flow and the confirmation 
flag is ON. Thai, the node device R4 transmits the label 
allocation messages m6 (Rowid = Egress [R1], Label = 
f, Hopcount = 4) to the node device R5 which is the 
neighboring node other than the next hop node. 
[0317] Upon receiving the label allocation message 
m7 from the node device R5, the node device R4 
returns the label allocation failure message to the node 
device R5 because the node device R5 is not the next 
hop node of this flow. 

[0318] Upon receiving the label allocation message 
m6 from the node device R4, the node device R5 
returns the label allocation failure message to the node 
device R4 because the node device R4 is not the next 
hop node of this flow. 

[0319] Upon receiving the label allocation success 
message from the node device R4, the node device R3 
registers Label = e, and thereafter the label switching 
between the input side label Label = e and the output 
side label Label = c becomes possible. 
[0320] Upon receiving the label allocation success 
messages from the node devices R5, R3 and R6, the 
node device R2 registers the respective input side 
labels Label = b, Label = c and Label = d, and thereafter 
the label switching between these input side labels and 
the output side Label = a becomes possibla 
[0321] Upon receiving the label allocation success 
message from the node device R2, the node device R1 
registers the input side label Label = a. 
[0322] As a result the merged label switched path as 
shown in Rg. 26 can be formed. 
[0323] Next, the exemplary operation at a time of the 
route change will be descrbed, for an exemplary case 
where the route change occurred at the node device R5 
in Rg. 26 such that the next hop node for Flcwtd = 
Egress [R1] is changed from R2 to R4. 
[0324] In such a case, the packet exchanges as 
shown in Rg. 27 are carried out in conjunction with the 
route change. In Rg. 27, REL denotes the label release 
message, REL_ACK denotes the label release success 
message, TRG denotes the label allocation trigger mes- 
sage, SETUP denotes the label allocation message, 
and SETUP_ACK denotes the label allocation success 
message. 

[0325] Rrst the node device R5 transmits the label 
release message to the node device R2 which is the 
next hop node before the route change, and turns the 
confirmation flag OFF. 

[0326] Upon receiving the label release message from 
the node device R5, the node device R2 releases the 
label allocation between the own device and the node 
device R5, and returns the label release success mes- 
sage to the node device R5. 
[0327] Upon receiving the label release success mes- 
sage from the node device R2, the node device R5 
turns the confirmation flag ON, and transmits the label 



allocation trigger message to the node device R4 which 
is the next hop node on a new route. 
[0328] Upon receiving the label allocation trigger mes- 
sage from the node device R5, the node device R4 
5 returns the label allocation message to the node device 
R5. 

[0329] Upon receiving the label allocation message 
from the node device R4, the node device R5 allocates 
the output side label between the own node and the 

io node device R4 and transmits the label allocation suc- 
cess message to the node device R4, because the node 
device R4 is the next hop node of this flow, the received 
hop count does not exceed the threshold, the confirma- 
tion flag is ON, it is not the egress node itself, and the 

is input side label does not exist. 

[0330] Upon receiving the label allocation success 
message from the node device R5, the node device R4 
cancels a response to the label allocation success mes- 
sage waiting state, and turns the confirmation flag ON. 

20 Thereafter, the label switching becomes possible at the 
node device R4. 

[0331] As a result the label switched path as shown 
in Rg. 28 can be formed. 

[0332] Next suppose that the further route change 
25 occurred from a state of Rg. 28 such that the next hop 
node of R2 is changed from R1 to R5. In this case, the 
route becomes a looping one in the sequence of R2 -> 
R5->R4->R3->R2fbr Rowid = Egress [R1]. 
[0333] In such a case, the packet exchanges as 
30 shown in Rg. 29 are carried out in conjunction with the 
route change. In Rg. 29, REL denotes the label release 
message, REL_ACK denotes the label release success 
message, TRG denotes the label allocation trigger mes- 
sage, SETUP denotes the label allocation message, 
35 QRY denotes the query message, QRY_NACK denotes 
the query failure message, UPD denotes the update 
message, and UPD_NACK denotes the update failure 
message. 

[0334] Rrst, the node device R2 transmits the label 
40 release message to the node device R1 which is the 
next hop node before the route change, and turns the 
confirmation flag OFF. 

[0335] Upon receiving the label release message from 
the node device R2, the node device R1 releases the 

45 label allocation between the own device and the node 
device R2, and returns the label release success mes- 
sage to the node device R2. 
[0336] Upon receiving the label release success mes- 
sage from the node device R1, the node device R2 

so turns the confirmation flag ON, and transmits the label 
allocation trigger message to the node device R5 which 
is the next hop node on a new route. 
[0337] Upon receiving the label allocation trigger mes- 
sage from the node device R2, the node device R5 

55 returns the label allocation message to the node device 
R2. 

[0338] Upon receiving the label allocation message 
from the node device R5, the node device R2 transmits 
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the query message to the node device R5 and turns the 
confirmation flag OFF, because the node device R5 is 
the next hop node of this flow, the received hop count 
does not exceed the threshold, the confirmation flag is 
ON, it is not the egress node rtseff, and the output side 5 
label does not exist despite that the input side label 
exists. 

[0339] Upon receiving the query message from the 
node device R2, the node device R5 turns the confirma- 
tion flag OFF, and transmits the update message to the 10 
node device R4 which is a neighboring node for which 
the output side label exists. 

[0340] Upon receiving the update message from the 
node device R5. the node device R4 turns the confirma- 
tion flag OFF, and transmits the update message to the is 
node device R3 which is a neighboring node for which 
the output side label exists. 

[0341] Upon receiving the update message from the 
node device R4, the node device R3 turns the confirma- 
tion flag OFF, and transmits the update message to the 20 
node device R2 which is a neighboring node for which 
the output side label exists. 

[0342] Upon receiving the update message from the 
node device R3, the node device R2 returns the update 
failure message to the node device R3 because the 25 
confirmation flag is OFF. 

[0343] Upon receiving the update failure message 
from the node device R2, the node device R3 returns 
the update failure message to the node device R4, and 
turns the confirmation flag ON. 30 
[0344] Upon receiving the update failure message 
from the node device R3, the node device R4 returns 
the update failure message to the node device R5, and 
turns the confirmation flag ON. 

[0345] Upon receiving the update failure message 35 
from the node device R4, the node device R5 returns 
the query failure message to the node device R2, and 
turns the confirmation flag ON. 
[0346] Upon receiving the query failure message from 
the node device R5, the node device R2 returns the 40 
label allocation failure message to the node device R5, 
and turns the confirmation flag ON. 
[0347] Upon receiving the label allocation failure mes- 
sage from the node device R2, the node device R5 
releases the input side label between the own node and as 
the node device R2. 

[0348] As a result, the loop-free label switched path as 
shown in Fig. 30 can be formed, despite of the fact that 
the route is looping. 

[0349] Next, the operation procedure of the node that so 
received the label allocation message in this fourth 
embodiment wfll be described with reference to Fig. 31 . 
[0350] Initially, the flow ID in the received message is 
settobeF(stepS301). 

[0351] Then, if the next hop of the packet flow identi- ss 
tied by F is different from the label allocation message 
source node (step S302 NO), or rf the received hop 
count exceeds the threshold (step S303 NO), or if it is 



the egress node itself (step S304 YES), the label alloca- 
tion failure message is returned to the label allocation 
message source node (step $305). 
[0352] Otherwise, if there exists a flow table entry wfth 
the flow ID = F and the output side label allocated (step 

5306 YES), the label allocation failure message is 
returns to the label allocation message source node 
(step S305) when the confirmation flag is OFF (step 

5307 NO), or the label allocation success message is 
returns to the label allocation message source node 
(step S309) when the confirmation flag is ON (step 
S307YES). 

[0353] Otherwise, rf there exists a flow table entry with 
the flow ID = F and the input side label allocated (step 

5308 YES), for each flow table entry with the fbw ID = 
F and the input side label allocated, the output side label 
is allocated and the query message is transmitted while 
the confirmation flag is turned OFF (step S310). If there 
is no flew table entry with the flow ID = F and the input 
side label allocation (step S308 NO), the label allocation 
success message is returned to the label allocation 
message source node (step S309). 

(Frfth Embodiment) 

[0354] Next, the case of carrying out the loop detec- 
tion using the ingress node information and the hop 
count from the ingress node in addition to the confirma- 
tion flag in the Egress control will be descrfeed. 
[0355] Initially, every node initializes the confirmation 
flag to ON state. 

[0356] The egress node transmits the label allocation 
message in which the hop count = 1 is specified to all 
the upstream side neighboring nodes (neighboring 
nodes other than the next hop node) of the flew. 
[0357] When the output side label for that flow is set 
up, the node other than the egress node transmits the 
label allocation message in which the hop count 
obtained by incrementing the hop count received from 
the egress node by one is specified to all the upstream 
side neighboring nodes (neighboring nodes other than 
the next hop node) of the flow. For those upstream side 
neighboring nodes for which the input side label does 
not exist, the label allocation message is transmitted 
regularly. 

[0358] A node U that received the label allocation 
message returns the label allocation failure message if 
a message source node D is not a next hop node for 
that flow, or if the received hop count exceeds the 
threshold, or if the confirmation flag is OFF, or rf it is the 
egress node itseH. When none of these conditions 
holds, if the output side label does not exist despite that 
the input side label exists, the confirmation flag is turned 
OFF and a "query message" that contains the ingress 
node information held at the node U and the hop count 
obtained by incrementing the hop count received from 
the ingress node by one is transmitted to the node D. 
Otherwise, the label allocation success message is 
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transmitted to the node D. At this point if the output side 
label does not exist, the allocation of the output side 
label is carried out and the hop count in the message is 
stored as the hop count from the egress node. 
[0359] Here, however, in the case of the ingress node 
which transmits the label allocation success message, 
the router ID of the own node or the network address of 
the output interface is set to be the ingress node 
address, the newly allocated ingress node local ID is set 
to be the ingress node, and the hop count = 1 is speci- 
fied (the transmission of the ingress node information). 
When it is not the ingress node itself, none of them are 
specified. 

[0360] The node that received the label allocation suc- 
cess message from the upstream side neighboring 
node becomes capable of carrying out the label witch- 
ing between the input side label and the output side 
label thereafter, unless it is the egress node itself. 
[0361] When the ingress node information and the 
hop count are specified in the received message, these 
are set in correspondence to the input side label, and if 
the received hop count is greater than the hop count 
corresponding to all the current input side labels and if it 
is not the egress node itserf, the update message that 
contains the received ingress node information and the 
hop count obtained by incrementing the received hop 
count by one is transmitted to the next hop node, and 
the confirmation flag is turned OFF (the forwarcfing of 
the ingress node information). 
[0362] The node that received the label allocation fail- 
ure message quits the registration of the input side 
label. 

[0363] In the case where the route change or the route 
deletion occurs at a node U on the path, the node U 
transmits the label release message to a next hop node 
Dold of an old route, and turns the confirmation flag 
OFF. 

[0364] The node Dold that received the label release 
message returns the label release failure message if the 
confirmation flag is OFF, or transmits the label release 
success message to the node U and releases the label 
if the confirmation flag is ON. In addition, when the 
ingress node having the maximum hop count is 
changed after the release, the confirmation flag is 
turned OFF and the update message specifying the 
(ingress node information, hop count) set after the 
change is transmitted to the downstream side nodes. 
[0365] The node U that received the label release suc- 
cess message turns the confirmation flag ON, and if 
there is a downstream side node Dnew of a new route, 
transmits a label allocation trigger message to the node 
Dnew. The label allocation trigger message is regularly 
re-transmitted until the label allocation message is 
received from the node Dnew. 
[0366] The node Dnew that received the label alloca- 
tion trigger message returns to the node U the label 
allocation message in which the hop count obtained by 
incrementing the hop count from the egress node to the 



own node by one is specified, if the confirmation flag is 
ON and either it is the egress node itserf or the output 
side label exists. 

[0367] The node D that received the query message 

5 from the node U returns the query failure message to 
the node U if the received ingress node information is 
already set in correspondence to the other input side 
label, or if the node D itserf is the ingress node for the 
received ingress node information, or if there exists the 

io input side label for which the ingress node information is 
not yet set up, or rf the confirmation flag is OFF, and 
does not carry out the registration of the input side label. 
When none of these conditions are satisfied, if the 
received hop count is greater than the hop count corre- 

is sponding to all the current input side labels and if it is 
not the eg/ess node rtseff, the update message that 
contains the received ingress node information and the 
hop count obtained by incrementing the received hop 
count by one is transmitted to the downstream side 

20 neighboring node, and the confirmation flag is turned 
OFF. Otherwise, the query success message is trans- 
mitted to the node U. 

[0368] The node that received the update message 
from the upstream side neighboring node returns the 

25 update failure message if the received ingress node 
information is already set in correspondence to the 
other input side label, or if there exists the input side 
label for which the ingress node information is not yet 
set up. or if the confirmation flag is OFF. When none of 

30 these conditions are satisfied, H the received hop count 
is greater than the hop count corresponding to all the 
current input side labels and if it is not the egress node 
itself, the update message that contains the received 
inpjess node information and the hop count obtained by 

35 incrementing the received hop count by one is transmit- 
ted to the downstream side neighboring node, and the 
confirmation flag is turned OFF. Otherwise, the update 
success message is returned, and the update of the 
ing/ess node information and the hop count is carried 

40 OUt. 

[0369] The node that received the update success 
message from the downstream side neighboring node 
turns the confirmation flag ON, and decides upon the 
update of the ingress node information and the hop 

45 count Then, the update success message is returned 
to the upstream side neighboring node that is waiting a 
response to the update message if such a node exists, 
while the query success message is returned to the 
upstream side neighboring node that transmitted the 

so query message if such a node exists. 

[0370] The node that received the update failure mes- 
sage from the downstream side neighboring node turns 
the confirmation flag ON, and quits the update of the 
ing/ess node information and the hop count Then, the 

55 update failure message is returned to the upstream side 
neighboring node that is waiting a response to the 
update message if such a node exists, while the query 
failure message is returned to the upstream side neigh- 
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boring node that transmitted the query message if such 
a node exists. 

[0371] The node U that received the query success 
message from the node D registers the output side label 
and turns the confirmation flag ON. Thereafter, the label s 
switching between the input side label and the output 
side label becomes possftxa 
[0372] The node U that received the query failure 
message from the node D turns the confirmation flag 
ON. Thereafter, the label switching between the input w 
side label and the output side label is not carried out 
[0373] Next the exemplary operation at a time of the 
label switched path generation win be described. Here, 
it is assumed that the router ID of a node is used as the 
ingress node information. is 
[0374] tn Fig. 32, it is assumed that R1 is the egress 
noda It is also assumed that the next hop nodes of R2, 
R3, R4, R5, R6, R7 and R8 are respectively R1, R2, R3, 
R2 ( R3, R6 and R7. Fig. 32 shows a state of the path 
after the initial generation process of the Egress control 20 
similar to that of the fourth embodiment. 
[0375] Here, the ingress nodes R5, R4 and R8 specify 
the ingress node information and the hop count in the 
label allocation success message, and each node for- 
wards to the downstream side neighboring node the 25 
label allocation success message specifying the ingress 
node information that gives the maximum hop count 
among the label allocation success messages received 
from the upstream side neighboring nodes and the hop 
count obtained by incrementing the corresponding hop 30 
count by ona As a result, the (ingress node information, 
hop count) sets that are notified by the nodes R5, R4, 
R8, R7, R6, R3 and R2 to the respective downstream 
side neighboring nodes become (R5, 1), (R4, 1), (R8, 
1), (R8, 2), (R8. 3). (R6, 4), and (R8, 5), respectively. 35 
[0376] Next, the exemplary operation at a time of the 
route change will be described, for an exemplary case 
where the route change occurred at the node device R5 
in Fig. 32 such that the next hop node for Flowid - 
Egress [R1] is changed from R2 to R4. 40 
[0377] In such a case, the packet exchanges as 
shown in Fig. 33 are earned out in conjunction with the 
route change, tn Fig. 33, REL denotes the label release 
message, REL_ACK denotes the label release success 
message. TRG denotes the label allocation trigger mes- 45 
sage, SETUP denotes the label allocation message, 
SETUP_ACK denotes the label allocation success mes- 
sage, UPD denotes the update message, and the 
UPD_ACK denotes the update success message. 
[0378] First, the node device R5 transmits the label so 
release message to the node device R2 which is the 
next hop node before the route change, and turns the 
confirmation flag OFF. 

[0379] Upon receiving the label release message from 
the node device R5. the node device R2 releases the ss 
label allocation between the own device and the node 
device R5, and returns the label release success mes- 
sage to the node device R5. 



[0380] Upon receiving the label release success mes- 
sage from the node device R2, the node device R5 
turns the confirmation flag ON, and transmits the label 
allocation trigger message to the node device R4 which 
is the next hop node on a new routa 
[0381 ] Upon receiving the label allocation trigger mes- 
sage from the node device R5. the node device R4 
returns the label allocation message to the node device 
R5. 

[0382] Upon receiving the label allocation message 
from the node device R4, the node device R5 transmits 
the label allocation success message to the node 
device R4, because the node device R4 is the next hop 
node of this flow, the received hop count does not 
exceed the threshold, the confirmation flag is ON, it is 
not the e&ess node itself, and the input side label does 
not exist In the label allocation success message, 
(ingress node information, hop count) = (R5, 1) is spec- 
ified. 

[0383] Upon receiving the label allocation success 
message from the node device R5, the node device R4 
transmits the update message specifying (ingress node 
information, hop count) = (R5, 2) to the next hop node 
R3, and turns the confirmation flag ON. 
[0384] Upon receiving the update message from the 
node device R4, the node device R3 sets the received 
(ingress node information, hop count) = (R5, 2) in corre- 
spondence to the input side label Label = d, and returns 
the update success message to the node device R3. 
[0385] Upon receiving the update success message 
from the node device R3, the node device R4 turns the 
confirmation flag ON. Thereafter the label switching 
between the input side label and the output side label 
becomes possible. 

[0386] As a result the label switched path as shown 
in Fig. 34 can be formed. 

[0387] Next, suppose that the further route change 
occurred from a state of Fig. 34 such that the next hop 
node of R2 is changed from R1 to R5. tn this case, the 
route becomes a looping one in the sequence of R2 -+ 
R5->R4-»R3-»R2for Flowid = Egress [R1]. 
[0388] In such a case, the packet exchanges as 
shown in Fig. 35 are carried out in conjunction with the 
route change. In Fig. 35, REL denotes the label release 
message, REL_ACK denotes the label release success 
message, TRG denotes the label allocation trigger mes- 
sage, SETUP denotes the label allocation message, 
QRY denotes the query message, QRY_NACK denotes 
the quay failure message, UPO denotes the update 
message, and UPDJMACK denotes the update failure 
message. 

[0389] First, the node device R2 transmits the label 
release message to the node device R1 which is the 
next hop node before the route change, and turns the 
confirmation flag OFF. 

[0390] Upon receiving the label release message from 
the node device R2, the node device R1 releases the 
label allocation between the own device and the node 
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device R2, and returns the label release success mes- 
sage to the node device R2. 
[0391 ] Upon receiving the label release success mes- 
sage from the node device R1. the node device R2 
turns the confirmation flag ON, and transmits the label s 
allocation trigger message to the node device R5 which 
is the next hop node on a new route. 
[0392] Upon receiving the label allocation trigger mes- 
sage from the node device R2, the node device R5 
returns the label allocation message to the node device 10 
R2. 

[0393] Upon receiving the label allocation message 
from the node device R5, the node device R2 transmits 
the query message to the node device R5 and turns the 
confirmation flag OFF In the query message, (ingress is 
node information, hop count) = (R8, 5) is specified. 
[0394] Upon receiving the query message from the 
node device R2, the node device R5 turns the confirma- 
tion flag OFF. and transmits the update message to the 
next hop node device R4. In the update message, 20 
(ingress node information, hop count) = (R8, 6) is spec- 
ified. 

[0395] Upon receiving the update message from the 
node device R5, the node device R4 turns the confirma- 
tion flag OFF, and transmits the update message to the 25 
next hop node device R3. In the update message, 
(ingress node information, hop count) = (R8, 7) is spec- 
ified. 

[0396] Upon receiving the update message from the 
node device R4, the node device R3 judges that there is 30 
a loop because the received ingress node information 
R8 is already set in correspondence to the output side 
label Label = e that was allocated between the own 
node and the node device R6, and returns the update 
failure message to the node device R4. 35 
[0397] Upon receiving the update failure message 
from the node device R3, the node device R4 returns 
the update failure message to the node device R5 and 
turns the confirmation flag ON. 

[0398] Upon receiving the update failure message 40 
from the node device R4, the node device R5 returns 
the query failure message to the node device R2, and 
turns the confirmation flag ON. 
[0399] Upon receiving the query failure message from 
the node device R5, the node device R2 turns the con- 45 
firmation flag ON. Thereafter the label switching 
between the input side label and the output side label is 
not carried out. 

[0400] As a result, the loop-free label switched path as 
shown in Fig. 36 can be formed, despite of the fact that so 
the route is looping. 

[0401] Note that, in this f ifth embodiment, the case of 
using the ingress node information and the hop count 
from the ingress node in addition to the confirmation 
flag has been described, but it is also possible to cany ss 
out the loop detection without using either the ingress 
node information or the hop count similarty as in the first 
and second embodiments described above. 



[0402] Next the operation procedure of the node that 
received the label allocation message in this fifth 
embocfiment will be described with reference to Fig. 37. 
[0403] Initially, the flow ID in the received message is 
set to be F (step S3 11). 

[0404] Then, whether there exists a flow table entry E 
with flow ID = F and the input side label matching with 
the received label or not is checked (step S312). If no 
such entry exists, the update failure message is trans- 
mitted to the update message source node (step S315). 
If such an entry E exists, whether there exists a flow 
table entry with flow ID = F and no ingress node infor- 
mation or not is checked (step S313). If such an entry 
exists, the update failure message is transmitted to the 
update message source node (step S3 15). ff no such 
entry exists, and if the confirmation flag of the entry E is 
OFF (step S314 NO), the update failure message is 
transmitted to the update message source node (step 
S315). If the confirmation flag of the entry E is ON (step 
S314 YES), the received ingress node information and 
hop count from the ingress node are registered into the 
entry E (step S316). 

[0405] Next, whether the received hop count is greater 
than the hop counts from the ingress node of all the 
table entries with flew ID = F (other than the entry E) or 
not is checked (step S3 17). ff not, the update success 
message is transmitted to the update message source 
node (step S319). Otherwise, whether it is the egress 
node itself or not is checked (step S318). ff so, the 
update success message is transmitted to the update 
message source node (step S31 9). Otherwise, the con- 
firmation flag is turned OFF and the update message is 
transmitted to the next hop node (step S320). 
[9406] Next, the case of transmitting the update mes- 
sage for the purpose of the loop detection into a direc- 
tion opposite to that of the path in the fourth and fifth 
embodiments will be described. 
[0407] In this case, the node that transmitted the label 
allocation message turns the confirmation flag OFF, and 
the node that was supposed to transmit the query mes- 
sage transmits the update message to the upstream 
side neighboring node for which the input side label 
exists and turns the confirmation flag OFF, instead of 
transmitting the query message. The update message 
is then successively forwarded to the upstream side 
neighboring nodes for which the input side labels exist, 
and when the update message is received by the node 
at which the confirmation flag is OFF, it is judged that 
there is a loop and the update failure message is 
returned. 

[0408] On the other hand, if the confirmation flag is 
ON when the ingress node receives the update mes- 
sage, the update success message is returned. When 
the update failure message is received from at least one 
upstream side neighboring node, the update failure 
message is returned to the downstream side neighbor- 
ing node, and otherwise the update success message is 
returned. In either case the confirmation flag is turned 
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ON. 

[0409] At the node that initially transmitted the update 
message, when the update failure message is received, 
the label allocation failure message is transmitted to the 
downstream side neighboring node, whereas when the 
update success message is received, the label alloca- 
tion success message is transmitted to the downstream 
side neighboring node. In either case the confirmation 
flag is turned ON. 

[0410] The label switching becomes possble at the 
node that received the label allocation success mes- 
sage, whereas the node that received the label alloca- 
tion failure message deletes the input side label. In 
either case the confirmation flag is turned ON. 
[0411] For example, in Fig. 36, The node device R5 
turns the confirmation flag OFF and transmits the label 
allocation message to the node device R5. Upon receiv- 
ing the label allocation message from the node device 
R5, the node device R2 turns the confirmation flag OFF 
and transmits the ipdate message to the node device 
R3. This update message is successively forwarded 
from the node device R3 to the node devices R4 and 
R6, from the node device R4 to the node device R5, 
from the node device R6 to the node device R7, and 
from the node device R7 to the node device R8. When 
the node device R5 receives the update message, it is 
judged that there is a loop because the confirmation flag 
is already OFF, and the update failure message is 
returned to the node device R4. Then the node device 
R4 returns the update failure message to the node 
device R3. On the other hand, the update success mes- 
sage is forwarded from the node device R8 to the node 
device R3. Then the node device R3 returns the update 
failure message to the node device R2. Upon receiving 
the update failure message, the node device R2 returns 
the label allocation failure message to the node device 
R5. 

[0412] Next, the operation in the case of having a 
node that does not carry out the label merging in the 
fourth and fifth embodiments will be descrbed. 
[0413] In this case, the label field is divided into the 
flow identification field and the ingress identification field 
at each node. The flow identification field is used for 
identifying the flow, while the ingress identification field 
is used in identifying the ingress node for each flow. 
[0414] The label switched path generation procedure 
is basically the same as in the fourth and fifth embodi- 
ments descrfoed above, except that the node which 
does not carry out the label merging specifies a value 
only to the flow identification field of the label, without 
specifying any value to the ingress identification field of 
the label, in the label allocation messaga Such a label 
win be referred to as "half allocation label". The node 
that carries out the label merging specifies values tor 
both the flow identification field and the ingress identifi- 
cation field of the label in the label allocation message. 
Such a label wifl be referred to as lull allocation label". 
In order to distinguish the half allocation label and the 



full allocation label, one bit of the label is used. 
[0415] When the label allocation message with the 
half allocation label specified arrives at the ingress 
node, the allocation of the full allocation label is carried 

5 out, and the allocated label is notified from the ingress 
node toward the e&ess node. For this notification, the 
update message is used. When the update message is 
received, if the full allocation label in the message is not 
yet registered, the received full allocation label is regis- 

10 tered as the input side label, and the allocation of the 
output side full allocation label corresponding to the 
input side label is carried out and then the update mes- 
sage containing the output side fufl allocation label is 
transmitted to the downstream side neighboring noda 

75 [0416] In addition, in the case where the node that 
received the label allocation message with the half allo- 
cation label specified transmits the query message to 
the next hop node, in correspondence to each input side 
full allocation label allocated to the flow, the output side 

20 fun allocation label using a value of the flow identifica- 
tion field in the message as a value of the flow identifi- 
cation field is allocated, and the query message 
containing the allocation output side label is transmitted 
for each allocated output side label. 

25 [041 7] Also, in the case where the update message is 
transmitted from the ipstream to the downstream and 
the node that received the query message transmits the 
update message, in correspondence to the full alloca- 
tion label written in the query message, the output side 

30 full allocation label using a value of the flow identifica- 
tion field in the message as a value of the flow identifi- 
cation field is allocated, and this is written into the 
update message. Also, in the case where the node that 
received the update message transmits the update 

35 message, in correspondence to the full allocation label 
written in the update message, the output side full allo- 
cation label using a value of the flow identification field 
in the message as a value of the flow identification field 
is allocated, and this is written into the tpdate message. 

40 [0418] For example, in Rg. 29, assuming that every 
node does not carry out the label merging, the node 
device R2 transmits two query messages including the 
query message that contains the full allocation label 
that was allocated for the path whose ingress node is 

45 the node device R5 and the query message that con- 
tains the full allocation label that was allocated for the 
path whose ingress node is the node device R6. Also, 
the node devices R5, R4 and R3 respectively transmits 
to the node devices R4, R3 and R2 the update message 

50 that contains the full allocation label that was allocated 
for the path whose ing-ess node is the node device R5, 
and the update message that contains the full allocation 
label that was allocated for the path whose ingress node 
is the node device R6. 

55 [0419] On the other hand, in the case where the 
update message is transmitted from the downstream to 
the upstream and the node transmits the update mes- 
sage, the already allocated half allocation label is writ- 



34 



67 

ten into the update message. 
[0420] Note that, tor the half allocation message, both 
the Upstream label allocation and the Downstream label 
allocation are possible, whereas for the full allocation 
label, the Upstream label allocation is preferable. s 
[0421 ] Also, in the case of using VPI/VCI as the label, 
VPI or VCI is used as the flow identification field or the 
ingress identification field. 

[0422] Next, the case of generating the label switched 
path for muHipath in the Egress control will be 
descrbed. 

[0423] In the case of generating the label switched 
path for mullipalh, at a branching node of the murtipath, 
separate labels are registered for the label allocation 
messages from the respective downstream side neigh- 
boring nodes of the muttipath, and the separate label 
allocation messages are transmitted to the respective 
upstream side neighboring nodes. 
[0424] Also, when one route of the muttipath is 
deleted, the label release messages for releasing the 
label switched path corresponding to the deleted route 
are transmitted to the respective upstream side neigh- 
boring nodes. The label release message is forwarded 
to the ingress node. 

[0425] Next, the exemplary message format to be 
used in the fourth and fifth embodiments will be 
descrbed. 

[0426] The format for the label allocation message, 
the label allocation success message, the label alloca- 
tion failure message, the label release message, the 
label release success message, the label release failure 
message, the update message, the update success 
message, and the update failure message is the same 
as that shown in Fig. 11 or Fig. 12, except that the label 
value is to be specified in the update message, the 
update success message, and the update failure mes- 
sage. Also, the format for the query message and the 
query success message is the same as that shown in 
Fig. 1 1 , and the format for the query failure message is 
the same as that shown in Fig. 12, except that the label 
value is to be specified in these messages. In addition, 
in these messages, the field for the ingress node infor- 
mation or the hop count may be omitted in the case of 
not using the ingress node information or the hop count 
[0427] Also, the format for the label allocation trigger 
message can be obtained by omitting the fields for the 
ingress node address, the ingress node local ID, the hop 
count, the label, and the request ID from the format 
shown in Fig. 1 1 . 

[0428] Next an exemplary configuration of the node 
device according to the present invention will be 
descrbed with reference to Fig. 38. 
[0429] The node device 1 0 of Fig. 38 comprises a con- 
trol message processing unit 11, a switch unit 12, a 
label information table 13, and a plurality of labelled 
frame transmission and reception units 14-1 to 14-n. 
[0430] In this node device 1 0. the labelled frames are 
entered from external devices, switched at the switch 
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unit 12, and then outputted to the external devices. 
[0431] Each labelled frame transmission and recep- 
tion unit 14 enters the labelled frame from the external 
device or the switch unit 12, refers to the label value 
written in the header of the frame, and if necessary, car- 
ries out the rewriting of the header of the labelled frame 
and the attaching/removing of an internal header which 
is necessary in switching frames at the switch unit 12, 
according to the label information stored in the label 
information table 13, and then outputs the lebeOed 
frame to the switch unit 12 or the external device. 
[0432] The switch unit 12 is a unit for switching and 
outputs ng the labelled frame received from one labelled 
frame transmission and reception unft 14 to another 
labelled frame transmission and reception unit 14 or the 
control message processing unit 11 according to the 
internal header information. 

[0433] The control message processing unit 11 car- 
ries the protocol message processing used for the pur- 
pose of the label allocation/release and the label 
switched path loop detection, as well as reading/writing 
of information with respect to the label information table 
according to the need. 

[0434] The label information table 13 stores the flow 
table containing information on the input side label and 
the output side label. 

[0435] As described, according to the present inven- 
tion, it becomes possible to detect a loop quicker than 
the conventional method using the hop count Also, 
according to the present invention, it becomes possble 
to detect a loop quickly even in the case of using the 
label merging. 

[0436] Note that the above description is mainly 
directed to an exemplary case where it is judged that 
there is a loop when the label allocation or update mes- 
sage having the same ingress node information for the 
same packet flow as the previously received label allo- 
cation or update message is received in relation to a dif- 
ferent input link (received from a different previous hop 
node or received as a message with a different input 
side label), but rt is possble to loosen this loop judge- 
ment condition such that there can be cases where it is 
not judged that there is a loop even when the above 
condition is satisfied. 

[0437] Similarly, for the case of using the confirmation 
flag, the above description is mainly directed to an 
exemplary case where it is judged that there is a loop 
when the label allocation/update message is received 
for the packet flow for which the state is pending, but it 
is also possible to loosen this loop judgement condition 
by using additional information contained in the mes- 
sage as well. 

[0438] In these variations, when the label alloca- 
tion/update message is received, whether this message 
contains the same flow ID and the same ingress node 
information as the previously received label alloca- 
tion/update message and is related to the different input 
link or not, or whether this message contains the same 
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flow ID as the previously received label alloca- 
tion/update message that is in the state of pending or 
not, is utilized as at least a part of criteria for judging 
whether there is a loop or not. similarly as in the embod- 
iments described above, so that these variations should 
also be properly construed as contained in the scope of 
the present invention. 

[0439] Also, the above description is mainly directed 
to an exemplary case where the failure message 
(NACK) is returned when it is judged that there is a loop; 
but rt is possWe to modify this processing variously (not 
returning ACK rather than returning NACK, for exam- 
ple), and these variations should also be properly con- 
strued as contained in the scope of the present 
invention. 

[0440] Note also that the above description presup- 
poses the hard state type protocol in which the label 
allocation message is not transmitted to the path to 
which the label is allocated once, but the present inven- 
tion is also effective for the soft state type protocol in 
which the label allocation message is transmitted regu- 
larly even for the path to which the label is allocated 
once. In the case of the soft state type protocol, the 
label is released when the label allocation message is 
not received for a prescribed period of time. 
[0441] It is to be noted that the above descrbed 
embodiments according to the present invention may be 
conveniently implemented using a conventional general 
purpose digital computer programmed according to the 
teachings of the present specification, as will be appar- 
ent to those skilled in the computer art Appropriate soft- 
ware coding can readily be prepared by skilled 
programmers based on the teachings of the present dis- 
closure, as will be apparent to those skilled in the soft- 
ware art. 

[0442] In particular, the node device in any of the 
above described embodiments can be conveniently 
implemented in a form of a software package. 
[0443] Such a software package can be a computer 
program product which employs a storage medium 
including stored computer code which is used to pro- 
gram a computer to perform the disclosed function and 
process of the present invention. The storage medium 
may include, but is not limited to, any type of conven- 
tional floppy disks, optical disks, CD-ROMs, magneto- 
optical disks, ROMs. RAMs, EPROMs. EEPROMs, 
magnetic or optical cards, or any other suitable media 
for storing electronic instructions. 
[0444] ft is also to be noted that, besides those 
already mentioned above, many modifications and vari- 
ations of the above embodiments may be made without 
departing from the novel and advantageous features of 
the present invention. Accordingly, all such modifica- 
tions and variations are intended to be included within 
the scope of the appended claims. 



Claims 

1. A node device for label switching entered packets 
by referring to an input label information capable of 

5 identifying a packet f tow to be entered and a corre- 
sponding information for specifying at least an out- 
put side interface, the node device comprising: 

a memory unit for storing a flow ID capable of 
10 network globally identifying a packet flow and 

an ingress node information regarding an 
ingress node of a label switched path, accord- 
ing to one label allocation message requesting 
a set up of the label switched path which is 
is received from one previous hop node; and 

a judging unit for judging whether a label 
switched path loop is formed or not according 
to from which node another label allocation 
message that contains an identical flow ID and 
20 an identical ingress node information as said 

one label allocation message is received. 

2. The node device of claim 1, wherein the judging 
unit judges whether the label switched path loop is 

25 formed or not according to whether or not said 
another label allocation message is received from a 
node different from said one previous hop node. 

3. The node device of claim 1, further comprising a 
30 processing unit for carrying out a label allocation 

processing with respect to a received label alloca- 
tion message, except when the judging unit judges 
that a label switched path loop is formed. 

35 4. The node device of claim 1 , further comprising a 
transmission unit for transmitting a label allocation 
failure message to a previous hop node which is a 
source of a received label allocation message when 
the judging unit judges that a label switched path 

40 loop is formed. 

5. The node device of claim 4, wherein when a label 
allocation failure message is received from a next 
hop node, the transmission unit transmits a label 
45 allocation success message to a previous hop node 
from which a label allocation message correspond- 
ing to the label allocation failure message is 
received. 

so 6. The node device of claim 1 , wherein each label allo- 
cation message contains a label that constitutes a 
part or a whole of the label information that is allo- 
cated by a previous hop node which is a source of 
said each label allocation message, or an identifier 

55 for specifying a connection between a previous hop 
node and said node device that constitute a part of 
the label switched path from which the label can be 
derived. 
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7. The node device of daim 1, wherein each label allo- 
cation message contains an identifier for requesting 
label allocation, and the node device further com- 
prises: 

5 

a transmission unit for transmitting to a previ- 
ous hop node which is a source of a received 
label allocation message a label allocation suc- 
cess message that contains a label thai consti- 
tutes a part or a whole of the label information io 
that is allocated by said node device, or an 
identifier for specifying a connection between a 
previous hop node and said node device that 
constitute a part of the label switched path from 
which the label can be derived, when a label is 
allocation processing with respect to the 
received label allocation message is permitted. 

8. The node device of claim 1 . further comprising: 

20 

a transmission unit for transmitting a message 
containing a hop count to a next hop node; and 
a processing unit for carrying out a label alloca- 
tion processing with respect to a received mes- 
sage, except when a hop count from the 25 
ingress node exceeds a threshold. 

9. The node device of claim 1, wherein the ingress 
node information is given by a network layer 
address allocated to an output interface of the 30 
ingress noda 



tng-ess node. 

13. The node device of claim 11. wherein the ingress 
node information is gven by a set of a network layer 
address allocated to an output interface of the 
ingress node and a local identifier allocated locally 
to the output interface of the ingress node. 

14, A node device for label switching entered packets 
by referring to an input side label information capa- 
ble of identifying a packet flow to be entered and a 
corresponding output label information capable of 
identifying the packet flow to be outputted. the node 
device (xxnprising: 

an exchange unit for exchanging with a neigh- 
boring node on a route of one packet flow a 
label allocation message requesting a set up of 
a label switched path which contains a flow ID 
capable of network globally identifying said one 
packet flow and an ingress node information 
regarding an ingress node of the label switched 
path; and 

a judging unit for judging whether a label 
switched path loop is formed or not when a 
label allocation message that contains a flow 
ID and an ingress node information that are 
matching with an existing label switched path is 
received, according to a change in the input 
side label information for the existing label 
switched path. 



10. The node device of claim 1. wherein the ingress 
node information is given by a set of a network layer 
address allocated to an output interface of the 35 
ingress node and a local identifier allocated locally 

to the output interface of the ingess noda 

11. A node device for transmitting packets to be label 
switched using an output label information capable 40 
of identifying a packet flow to be outputted. the 
node device comprising: 

a transmission unit for transmitting a label allo- 
cation message requesting a set up of a label 45 
switched path that contain at least an informa- 
tion on said node device as an ingress node 
information regarding an ingess node of the 
label switched path; and 

a judging unit for judging that a label switched so 
path loop is formed upon receiving a label allo- 
cation message in which the ingress node 
information specifies said node device as the 
ingress node. 

55 

12. The node device of claim 11. wherein the ingress 
node information is given by a network layer 
address allocated to an output interface of the 



15. The node device of claim 14, further comprising a 
processing unit for carrying out a label allocation 
processing with respect to a received label alloca- 
tion message, except when the judging unit judges 
that a label switched path loop is formed. 

16. The node device of claim 14, further comprising a 
transmission unit for transmitting a label allocation 
failure message to a previous hop node which is a 
source of a received label allocation message when 
the judging unit judges that a label switched path 
loop is formed. 

17. The node device of claim 16. wherein when a label 
allocation failure message is received from a next 
hop node, the transmission unit transmits a label 
allocation success message to a previous hop node 
from which a label allocation message correspond- 
ing to the label allocation failure message is 
received. 

18. The node device of claim 14. wherein each label 
allocation message contains a label that constitutes 
a part or a whole of the label information that is allo- 
cated by a previous hop node device which is a 
source of said each label allocation message, or an 
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identifier for specifying a connection between a pre- 
vious hop node and said node device that consti- 
tute a part of the label switched path from which the 
label can be derived. 

5 

19. The node device of claim 14, wherein each label 
allocation message contains an identifier for 
requesting label allocation, and the node device fur- 
ther comprises: 

10 

a transmission unit for transmitting to a previ- 
ous hop node which is a source of a received 
label allocation message a label allocation suc- 
cess message that contains a label that consti- 
tutes a part or a whole of the label information is 
that is allocated by said node device, or an 
identifier for specifying a connection between a 
previous hop node and said node device that 
constitute a part of the label switched path from 
which the label can be derived, when a label so 
allocation processing with respect to the 
received label allocation message is permitted. 

20. The node device of claim 1 4, further comprising: 

25 

a transmission unit for transmitting a message 
containing a hop count to a next hop node; and 
a processing unit for carrying out a label alloca- 
tion processing with respect to a received mes- 
sage, except when a hop count from the 30 
ingress node exceeds a threshold. 

21. The node device of claim 14, wherein the ingress 
node information is given by a network layer 
address allocated to an output interface of the 3s 
ingress node. 

22. The node device of claim 14, wherein the ingress 
node information is given by a set of a network layer 
address allocated to an output interface of the 40 
ingress node and a local identifier allocated locally 

to the output interface of the ingress node. 

23. A node device for label switching entered packets 

by referring to an input side label information capa- 45 
bfe of identifying a packet flow to be entered and 
corresponding one or a plurality of output label 
information capable of identifying the packet flow to 
be outputted, the node device comprising: 

50 

an exchange unit for exchanging with each one 
of a previous hop node and one or a plurality of 
next hop nodes on a route of one packet flow a 
label allocation message requesting a set up of 
a label switched path which contains an iderrti- ss 
tier for identifying said one packet flow and an 
ingress node information regarding an ingress 
node of the label switched path; and 
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a judging unit for detecting whether or not a 
message containing an identifier and an 
ingress node information that are identical to 
those of a previously exchanged message is 
received from a previous hop node different 
from one previous hop node from which the 
previously exchanged message is received, or 
whether or not a message that contains an 
identifier and an ingress node information that 
are identical to those of the previously 
exchanged message and changes the input 
side label information is received, and judging 
whether a label switched path loop is formed or 
not according to a result of detecting. 

24. The node device of claim 23, further comprising: 

a transmission unit for transmitting a message 
containing a hop count to a next hop node; and 
a processing unit for carrying out a label alloca- 
tion processing with respect to a received mes- 
sage, except when a hop count from the 
ingress node exceeds a threshold. 

25. A node device for label switching entered packets 
by referring to one or a plurality of input side label 
information capable of identifying a packet flow to 
be entered and a corresponding output label infor- 
mation capable of identifying the packet flow to be 
outputted, the node device comprising: 

an exchange unit for exchanging with a neigh- 
boring node on a route of one packet flow a 
message for setting up a new label switched 
path or utilizing an existing label switched path, 
which contains an identifier for identifying said 
one packet flow and an ingress node informa- 
tion regarding an ingress node of the new label 
switched path or the existing label switched 
path; and 

a judging unit for detecting whether or not a 
message containing an identifier and an 
ingress node information that are identical to 
those of a previously exchanged message is 
received from a previous hop node device dif- 
ferent from one previous hop node device from 
which the previously exchanged message is 
received, or whether or not a message that 
contains an identifier and an ingress node 
information that are identical to those of the 
previously exchanged message and changes 
the input side label information is received, and 
judging whether a label switched path loop is 
formed or not according to a result of detec- 
ting. 

26. The node device of claim 25, wherein the exchange 
unit transmits to a next hop node a label allocation 
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message as a message for setting up a new label 
switched path when no label switched path for said 
one packet flow exists on downstream side of said 
node device, and 

the exchange unit transmits to the next hop 
node an update message as a message for uti- 
lizing an existing label switched path when a 
label switched path for said one packet flow 
exists on downstream side of said node device 
and a corresponding label switched path is to 
be newly set up on upstream side of said node 
device. 

27. The node device of claim 25, wherein the exchange 
unit transmits to a node other than a next hop node 
a label allocation message as a message for setting 
up a new label switched path when a label switched 
path for said one packet flow exists on downstream 
side of said node device but no corresponding label 
switched path exists on upstream side of said node 
device, 

the exchange unit transmits to the next hop 
node a query message as a message for set- 
ting up a new label switched path when a label 
switched path for said one packet flow exists on 
upstream side of said node device but no corre- 
sponding label switched path exists on down- 
stream side of said node device, and 
the exchange unit transmits to the next hop 
node an update message as a message for uti- 
lizing an existing label switched path when the 
query message is received from a previous hop 
node and a label switched path for said one 
packet flow exists on downstream side of said 
node donee. 

28. The node device of claim 27, wherein the exchange 
unit transmits to the next hop node a label alloca- 
tion success message when the label allocation 
message is received from the next hop node and no 
label switched path for said one packet flow exists 
on upstream side of said node device, and 

the exchange unit also transmits the update 
message to the next hop node when the label 
allocation success message is received from a 
previous hop node and a label switched path 
for said one packet flow exists on downstream 
side of said node device. 

29. The node device of claim 25, further comprising: 

a transmission unit for transmitting a message 
containing a hop count to a next hop node; and 
a processing unit for carrying out a label alloca- 
tion processing with respect to a received mes- 
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sage, except when a hop count from the 
ingress node exceeds a threshold. 

30. A node device for label switching entered packets 
5 by referring to an input side label information capa- 
ble of identifying a packet flow to be entered and a 
corresponding output side label information capa- 
ble of identifying the packet flow to be outputted, 
and for merging label switched paths by setting one 

w output side label information and a plurality of input 
side label information in correspondence for one 
packet flow, the node device comprising: 

a transmission unit for transmitting to a next 
is hop node in an existing label switched path a 

hop count update message that contains at 
least an ingress node information after merging 
and an updated hop count value, upon receiv- 
ing one label allocation message requesting a 
20 set up of one label switched path that contains 

at least a given ingress node information 
regarding an ingress node of said one label 
switched path and a given hop count value, 
when said one label allocation message 
25 requires merging to the existing label switched 

path and the given hop count value makes a 
hop count value of the existing label switched 
path updated to a larger value than a current 
value; and 

30 a judging unit for judging whether a label 

switched path loop is formed or not according 
to from which node another hop count update 
or label allocation message for an identical 
packet flow that contains an identical ingress 
35 node information as a previously received label 

allocation message is received. 

31. The node device of claim 30, wherein the judging 
unit judges whether the label switched path loop is 

40 formed or not according to whether or not said 
another hop count update or label allocation mes- 
sage is received from a node different from a previ- 
ous hop node from which the previously received 
label allocation message is received. 

45 

32. The node device of claim 30, further comprising: 

a unit for notifying that hop count update or 
label allocation cannot be made to a previous 
so hop node from which a hop count update or 

label allocation message is received when the 
judging unit judges that a label switched path 
loop is formed; 

a unit for notifying that label allocation cannot 
55 be made to a previous hop node from which a 

label allocation message is received upon 
being notified that hop count update cannot be 
made; 
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a unit for notifying that hop count update can be 
made to a previous hop node from which a hop 
count update message is received upon being 
notified that label allocation cannot be made 
and when a hop count does not exceed a 
threshold; and 

a unit for setting up a set up requested label 
switched path by merging to the existing label 
switched path upon being notified that hop 
count update can be made. 

33. The node device of claim 30, further comprising: 

a unit for setting up a set up requested label 
switched path by merging to the existing label 
switched path, upon receiving said one label 
allocation message, when said one label allo- 
cation message requires merging to the exist- 
ing label switched path and the given hop count 
value does not make a hop count value of the 
existing label switched path updated to a larger 
value than a current value. 

34. The node device of claim 30, wherein the transmis- 
sion unit uses an information regarding an ingress 
node corresponding to the updated hop count value 
as the ingress node information after merging to be 
contained in the hop count update message, and 
transmits the hop count update message that con- 
tains an ingress node information and a hop count 
value after undoing merging, when a part of 
merged label switched path is released to undo 
merging and an in^ess node information corre- 
sponding to a released path is contained in the hop 
count update message. 

35. The node device of claim 30. wherein the transmis- 
sion unit uses an information regarding an ingress 
node corresponding to the updated hop count value 
or an ingress node of the existing label switched 
path as the ingress node information after merging 
to be contained in the hop count update message, 
and transmits an update message that contains an 
ingress node information after undoing merging, 
when a part of merged label switched path is 
released to undo merging and an ingress node 
information corresponding to a released path is 
contained in the hop count update message. 

36. A node device for label switching entered packets 
by referring to one or a plurality of input side label 
information capable of identifying a packet flow to 
be entered and a corresponding output label infor- 
mation capable of identifying the packet flow to be 
outputted, the node device comprising: 

an exchange unit for exchanging with a neigh- 
boring node on a route of one packet flow a 



message for setting up a new label switched 
path or utilizing an existing label switched path, 
which contains an identifier for identifying said 
one packet flow; 

a memory unit for storing an information indi- 
cating a set up of a label switched path corre- 
sponding to said message as pending until a 
response message corresponding to said mes- 
sage is received; and 

a judging unit for judging whether a label 
switched path loop is formed or not according 
to whether or not a message regarding a label 
switched path for which the information indicat- 
ing pending is stored in the memory unit 
according to a previously exchanged message 
is received. 

37. The node device of claim 36, wherein the exchange 
unit transmits to a next hop node a label allocation 
message as a message for setting up a new label 
switched path when no label switched path for said 
one packet flow exists on downstream side of said 
node device, and 

the exchange unit transmits to the next hop 
node an update message as a message for uti- 
lizing an existing label switched path when a 
label switched path for said one packet flow 
exists on downstream side of said node device 
and a corresponding label switched path is to 
be newly set up on upstream side of said node 
device. 

38. The node device of claim 36, wherein the exchange 
unit transmits to a next hop node a label allocation 
message as a message for setting up a new label 
switched path when no label switched path for said 
one packet flow exists on downstream side of said 
node device, 

the exchange unit transmits to the next hop 
node a query message as a message for set- 
ting up a new label switched path when a label 
switched path for said one packet flow exists on 
downstream side of said node device and a 
corresponding label switched path is to be 
newly set up on upstream side of said node 
device, and 

the exchange unit transmits to a previous hop 
node of one label switched path on upstream 
side of said node device an update message 
as a message for utilizing an existing label 
switched path when the query message is 
received from the next hop node and said one 
label switched path for said one packet flow 
exists on upstream side of said node device. 

39l The node device of claim 36, wherein the exchange 
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unit transmits to a node other than a next hop node 
a label allocation message as a message for setting 
up a new label switched path when a label switched 
path for said one packet flow exists on downstream 
side of said node device but no corresponding label 5 
switched path exists on upstream side of said node 
device, 

the exchange unit transmits to the next hop 
node a query message as a message for set- 10 
ting up a new label switched path when a label 
switched path for said one packet flow exists on 
upstream side of said node device but no corre- 
sponding label switched path exists on down- 
stream side of said node device, and is 
the exchange unit transmits to the next hop 
node an update message as a message for uti- 
lizing an existing label switched path when the 
query message is received from a previous hop 
node and a label switched path for said one 20 
packet flow exists on downstream side of said 
node dance. 

40. The node device of claim 36, wherein the exchange 
unit transmits to a node other than a next hop node 2s 
a label allocation success message as a message 

for setting up a new label switched path when a 
label switched path for said one packet flow exists 
on downstream side of said node device but no cor- 
responding label switched path exists on upstream 30 
side of said node device, and 

the exchange unit transmits to a previous hop 
node of one label switched path on upstream 
side of said node device an update message 35 
as a message for utilizing an existing label 
switched path when a label switched path for 
said one packet flow exists on upstream side of 
said node device but no corresponding label 
switched path exists on downstream side of 40 
said node device so that a corresponding label 
switched path is to be newly set up on 
upstream side of said node device. 

41. A node device for label switching entered packets 45 
by referring to an input side label information capa- 
ble of identifying a packet flow to be entered and a 
corresponding oulput side label information capa- 
ble of identifying the packet flow to be outputted, 
and for merging label switched paths by setting one so 
oulput side label information and a plurality of input 
side label information in correspondence for one 
packet flow, the node device comprising: 

a transmission unit for transmitting to a next ss 
hop node in an existing label switched path a 
hop count update message that contains at 
least an updated hop count value, upon receiv- 



ing one label allocation message requesting a 
set up of one label switched path that contains 
at least a given hop count value, when said one 
label allocation message requires merging to 
the existing label switched path and the given 
hop count value makes a hop count value of 
the existing label switched path updated to a 
larger value than a current value; 
a memory unit for storing a correspondence 
between the input side label information and 
the output side label information for said one 
packet flow according to said one label alloca- 
tion message, and storing an information indi- 
cating a storing of the correspondence as 
pending until a success message correspond- 
ing to the hop count update message is 
received; and 

a judging unit for judging whether a label 
switched path loop is formed or not according 
to whether or not a hop count update or label 
allocation message indicating a packet flow or 
a correspondence between the input side label 
information and the output side label informa- 
tion for which the information indicating the 
storing of the correspondence as pending is 
stored in the memory unit according to a previ- 
ously received label allocation message is 
received. 

42. A method of label switched path loop detection in a 
node device for label switching entered packets by 
referring to an input label information capable of 
identifying a packet flow to be entered and a corre- 
sponding information for specifying at least an out- 
put side interface, the method comprising the steps 
of: 

storing a flew ID capable of network globally 
identifying a packet flow and an ingress node 
information regarding an ingress node of a 
label switched path, according to one label allo- 
cation message requesting a set up of the label 
switched path which is received from one previ- 
ous hop node; and 

judging whether a label switched path loop is 
formed or not according to from which node 
another label allocation message that contains 
an identical flew ID and an identical ingress 
node information as said one label allocation 
message is received. 

43. A method of label switched path loop detection in a 
node device for transmitting packets to be label 
switched using an output label information capable 
of identifying a packet flow to be outputted, the 
method comprising the steps of: 

transmitting a label allocation message 
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requesting a set up of a label switched path 
that contain at least an information on said 
node device as an ingress node information 
regarding an ingress node of the label switched 
path; and 5 
judging that a label switched path loop is 
formed upon receiving a label allocation mes- 
sage in which the ingress node information 
specifies said node device as the ingress noda 

10 

44. A method of label switched path loop detection in a 
node device for label switching entered packets by 
referring to an input side label information capable 
of identifying a packet flow to be entered and a cor- 
responding output label information capable of is 
identifying the packet flow to be outputled, the 
method comprising the steps of: 

exchanging with a neighboring node on a route 
of one packet flow a label allocation message 20 
requesting a set up of a label switched path 
which contains a flew ID capable of network 
globally identifying said one packet flew and an 
ingress node information regarding an ingress 
node of the label switched path; and 25 
judging whether a label switched path loop is 
formed or not when a label allocation message 
that contains a flow ID and an ingress node 
information that are matching with an existing 
label switched path is received, according to a 30 
change in the input side label information for 
the existing label switched path. 

45. A method of label switched path loop detection in a 
node device for label switching entered packets by 35 
referring to an input side label information capable 

of identifying a packet flew to be entered and corre- 
sponding one or a plurality of output label informa- 
tion capable of identifying the packet flow to be 
outputted, the method comprising the steps of: 40 

exchanging with each one of a previous hop 
node and one or a plurality of next hop nodes 
on a route of one packet flow a label allocation 
message requesting a set up of a label 45 
switched path which contains an identifier for 
identifying said one packet flow and an ingress 
node information regarding an ingress node of 
the label switched path; and 
detecting whether or not a message containing so 
an identifier and an ingress node information 
that are identical to those of a previously 
exchanged message is received from a previ- 
ous hop node different from one previous hop 
node from which the previously exchanged ss 
message is received, or whether or not a mes- 
sage that contains an identifier and an ingress 
node information that are identical to those of 



the previously exchanged message and 
changes the input side label information is 
received, and judging whether a label switched 
path loop is formed or not according to a result 
of detecting. 

46. A method of label switched path loop detection in a 
node device for label switching entered packets by 
referring to one or a plurality of input side label infor- 
mation capable of identifying a packet flow to be 
entered and a corresponding output label informa- 
tion capable of identifying the packet flow to be out- 
putted, the method comprising the steps of: 

exchanging with a neighboring node on a route 
of one packet flow a message for setting up a 
new label switched path or utilizing an existing 
label switched path, which contains an identi- 
fier for identifying said one packet flow and an 
ingress node information regarding an ingress 
node of the new label switched path or the 
existing label switched path; and 
detecting whether or not a message containing 
an identifier and an ingress node information 
that are identical to those of a previously 
exchanged message is received from a previ- 
ous hop node device different from one previ- 
ous hop node device from which the previously 
exchanged message is received, or whether or 
not a message that contains an identifier and 
an ingress node information that are identical 
to those of the previously exchanged message 
and changes the input side label information is 
received, and judging whether a label switched 
path loop is formed or not according to a result 
of detectiong. 

47. A method of label switched path loop detection in a 
node device for label switching entered packets by 
referring to an input side label information capable 
of identifying a packet flow to be entered and a cor- 
responding output side label information capable of 
identifying the packet flew to be outputted, and for 
merging label switched paths by setting one output 
side label information and a plurality of input side 
label information in correspondence for one packet 
flow, the method comprising the steps of: 

transmitting to a next hop node in an existing 
label switched path a hop count update mes- 
sage that contains at least an ingress node 
information after merging and an updated hop 
count value, upon receiving one label alloca- 
tion message requesting a set up of one label 
switched path that contains at least a given 
ingress node information regarding an ingress 
node of said one label switched path and a 
given hop count value, when said one label 
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allocation message requires merging to the 
existing label switched path and the given hop 
count value makes a hop count value of the 
existing label switched path updated to a larger 
value than a current value; and 5 
judging whether a label switched path bop is 
formed or not according to from which node 
another hop count update or label allocation 
message for an identical packet flow that con- 
tains an identical ingress node information as a 10 
previously received label allocation message is 
received. 

48. A method of label switched path loop detection in a 
node device for label switching entered packets by 15 
referring to one or a plurality of input side label infor- 
mation capable of identifying a packet flow to be 
entered and a corresponding output label informa- 
tion capable of identifying the packet flow to be out- 
putted, the method comprising the steps ot 20 



switched path updated to a larger value than a 
current value; 

storing a correspondence between the input 
side label information and the output side label 
information for said one packet flow according 
to said one label allocation message, and stor- 
ing an information indicating a storing of the 
correspondence as pending until a success 
message corresponding to the hop count 
update message is received; and 
judging whether a label switched path loop is 
formed or not according to whether or not a hop 
count update or label allocation message indi- 
cating a packet flow or a correspondence 
between the input side label information and 
the output side label information for which the 
information indicating the storing of the corre- 
spondence as pending is stored in the memory 
unit according to a previously received label 
allocation message is received. 



exchanging with a neighboring node on a route 
of one packet flow a message for setting up a 
new label switched path or utilizing an existing 
label switched path, which contains an identi- 2s 
tier for identifying said one packet flow; 
storing an information indicating a set up of a 
label switched path corresponding to said mes- 
sage as pending untfl a response message cor- 
responding to said message is received; and 30 
judging whether a label switched path loop is 
formed or not according to whether or not a 
message regarding a label switched path for 
which the information indicating pending is 
stored in the memory unit according to a previ- 35 
ously exchanged message is received. 

49. A method of label switched path loop detection in a 
node device for label switching entered packets by 
referring to an input side label information capable ao 
of identifying a packet flow to be entered and a cor- 
responding output side label information capable of 
identifying the packet flow to be outputted, and for 
merging label switched paths by setting one output 
side label information and a plurality of input side 45 
label information in correspondence for one packet 
flow, the method comprising the steps of: 

transmitting to a next hop node in an existing 
label switched path a hop count update mes- so 
sage that contains at least an updated hop 
count value, upon receiving one label alloca- 
tion message requesting a set up of one label 
switched path that contains at least a given hop 
count value, when said one label allocation ss 
message requires merging to the existing label 
switched path and the given hop count value 
makes a hop count value of the existing label 



50. An article of manufacture, comprising: 

a computer usable medium having computer 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to an input label information capa- 
ble of identifying a packet flow to be entered 
and a corresponding information for specifying 
at least an output side interface, the computer 
readable program code means includes: 
first computer readable program code means 
for causing said computer to store a flow ID 
capable of network globally identifying a packet 
flow and an ingress node information regarding 
an ingress node of a label switched path, 
according to one label allocation message 
requesting a set up of the label switched path 
which is received from one previous hop node; 
and 

second computer readable program code 
means for causing said computer to judge 
whether a label switched path loop is formed or 
not according to from which node another label 
allocation message that contains an identical 
flow ID and an identical ingress node informa- 
tion as said one label allocation message is 
received. 

51. An article of manufacture, comprising: 

a computer usable medium having computer 
readable program code means embodied 
therein for causing a computer to function as a 
node device for transmitting packets to be label 
switched using an output label information 
capable of identifying a packet flow to be out- 
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putted, the computer readable program code 
means includes: 

first computer readable program code means 
for causing said computer to transmit a label 
allocation message requesting a set up of a s 
label switched path that contain at least an 
information on said node device as an ingress 
node information regarding an ingress node of 
the label switched path: and 
second computer readable program code w 
means for causing said computer to judge that 
a label switched path loop is formed upon 
receiving a label allocation message in which 
the ingress node information specifies said 
node device as the ingress node. 75 

52. An article of manufacture, comprising: 

a computer usable medium having computer 
readable program code means embodied zo 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to an input side label information 
capable of identifying a packet flow to be 
entered and a corresponding output label infer- 2s 
mation capable of identifying the packet flow to 
be outputted, the computer readable program 
code means includes: 

first computer readable program code means 
for causing said computer to exchange with a 30 
neighboring node on a route of one packet flow 
a label allocation message requesting a set up 
of a label switched path which contains a flow 
ID capable of network globally identifying said 
one packet flow and an ingress node informa- 3s 
tion regarding an ingress node of the label 
switched path; and 

second computer readable program code 
means for causing said computer to judge 
whether a label switched path loop is formed or 40 
not, when a label allocation message that con- 
tains a flow ID and an ingress node information 
that are matching with an existing label 
switched path is received, according to a 
change in the input side label information for 45 
the existing label switched path. 

53. An article of manufacture, comprising: 

a computer usable medium having computer so 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to an input side label information 
capable of identifying a packet flow to be ss 
entered and corresponding one or a plurality of 
output label information capable of identifying 
the packet flow to be outputted, the computer 



readable program code means includes: 
first computer readable program code means 
for causing said computer to exchange with 
each one of a previous hop node and one or a 
plurality of next hop nodes on a route of one 
packet flow a label allocation message request- 
ing a set up of a label switched path which con- 
tains an identifier for identifying said one packet 
flow and an ingress node information regarding 
an ingress node of the label switched path; and 
second computer readable program code 
means for causing said computer to detect 
whether or not a message containing an identi- 
fier and an ingress node information that are 
identical to those of a previously exchanged 
message is received from a previous hop node 
different from one previous hop node from 
which the previously exchanged message is 
received, or whether or not a message that 
contains an identifier and an ingress node 
information that are identical to those of the 
previously exchanged message and changes 
the input side label information is received, and 
judge whether a label switched path loop is 
formed or not according to a result of detecting. 

54. An article of manufacture, comprising: 

a computer usable medium having computer 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to one or a plurality of input side 
label information capable of identifying a 
packet flow to be entered and a corresponding 
output label information capable of identifying 
the packet flow to be outputted, the computer 
readable program code means includes: 
first computer readable program code means 
for causing said computer to exchange with a 
neighboring node on a route of one packet flow 
a message for setting up a new label switched 
path or utilizing an existing label switched path, 
which contains an identifier for identifying said 
one packet flow and an ingress node informa- 
tion regarding an ingress node of the new label 
switched path or the existing label switched 
path; and 

second computer readable program code 
means for causing said computer to detect 
whether or not a message containing an identi- 
fier and an ingress node information that are 
identical to those of a previously exchanged 
message is received from a previous hop node 
device different from one previous hop node 
device from which the previously exchanged 
message is received, or whether or not a mes- 
sage that contains an identifier and an ingress 
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node information that are identical to those of 
the previously exchanged message and 
changes the input side label information is 
received, and judge whether a label switched 
path loop is formed or not according to a result 5 
of detecting. 

55. An article of manufacture, comprising: 

a computer usable medium having computer 10 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to an input side label information 
capable of identifying a packet flow to be 75 
entered and a corresponding output side label 
information capable of identifying the packet 
flow to be outputted, and for merging label 
switched paths by setting one output side label 
information and a plurality of input side label 20 
information in correspondence for one packet 
flow, the computer readable program code 
means includes: 

first computer readable program code means 
for causing said computer to transmit to a next 2s 
hop node in an existing label switched path a 
hop count update message that contains at 
least an ingress node information after merging 
and an updated hop count value, upon receiv- 
ing one label allocation message requesting a 30 
set up of one label switched path that contains 
at least a given ingress node information 
regarding an ingress node of said one label 
switched path and a given hop count value, 
when said one label allocation message 35 
requires merging to the existing label switched 
path and the given hop count value makes a 
hop count value of the existing label switched 
path updated to a larger value than a current 
value; and 40 
second computer readable program code 
means for causing said computer to judge 
whether a label switched path loop is formed or 
not according to from which node another hop 
count update or label allocation message for an 45 
identical packet flow that contains an identical 
ingress node information as a previously 
received label allocation message is received. 

56. An article of manufacture, comprising: so 

a computer usable medium having computer 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 55 
by referring to one or a plurality of input side 
label information capable of identifying a 
packet flow to be entered and a corresponding 



output label information capable of identifying 
the packet flow to be outputted. the computer 
readable program code means includes: 
first computer readable program code means 
for causing said computer to exchange with a 
neighboring node on a route of one packet flow 
a message for setting up a new label switched 
path or utilizing an existing label switched path, 
which contains an identifier for identifying said 
one packet flow; 

second computer readable program code 
means for causing said computer to store an 
information indicating a set up of a label 
switched path corresponding to said message 
as pending until a response message corre- 
sponding to said message is received; and 
third computer readable program code means 
for causing said computer to judge whether a 
label switched path loop is formed or not 
according to whether or not a message regard- 
ing a label switched path for which the informa- 
tion indicating pending is stored in the memory 
unit according to a previously exchanged mes- 
sage is received. 

57. An article of manufacture, comprising: 

a computer usable medium having computer 
readable program code means embodied 
therein for causing a computer to function as a 
node device for label switching entered packets 
by referring to an input side label information 
capable of identifying a packet flow to be 
entered and a corresponding output side label 
information capable of identifying the packet 
flow to be outputted, and for merging label 
switched paths by setting one output side label 
information and a plurality of input side label 
information in correspondence for one packet 
flow, the computer readable program code 
means includes: 

first computer readable program code means 
for causing said computer to transmit to a next 
hop node in an existing label switched path a 
hop count update message that contains at 
least an updated hop count value, upon receiv- 
ing one label allocation message requesting a 
set up of one label switched path that contains 
at least a given hop count value, when said one 
label allocation message requires merging to 
the existing label switched path and the given 
hop count value makes a hop count value of 
the existing label switched path updated to a 
larger value than a current value; 
second computer readable program code 
means for causing said computer to store a 
correspondence between the input side label 
information and the output side label irrforma- 
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tion for said one packet flow according to said 
one label allocation message, and storing an 
information indicating a storing of the corre- 
spondence as pending until a success mes- 
sage corresponding to the hop count update 5 
message is received; and 
third computer readable program code means 
for causing said computer to judge whether a 
label switched path loop is formed or not 
according to whether or not a hop count update 10 
or label allocation message indicating a packet 
flow or a correspondence between the input 
side label information and the output side label 
information for which the information indicating 
the storing of the correspondence as pending is 
is stored in the memory unit according to a pre- 
viously received label allocation message is 
received. 
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